n Many failed systems were abandoned because analysts tried to build wonderful systems without understanding the organization.
n The primarily goal is to create value for the organization.
n The systems analyst is a key person analyzing the business, identifying opportunities for improvement, and designing information systems to implement these ideas.
n It is important to understand and develop through practice the skills needed to successfully design and implement new information systems.
THE SYSTEMS DEVELOPMENT LIFE CYCLE
n Planning (Why build the system? How should the team go about building it?)
n Analysis (Who uses system, what will it do, where and when will the system be used?)
n Design (How will the system work?)
n Implementation (System delivery)
n Identifying business value
n Analyze feasibility
n Develop work plan
n Staff the project
n Control and direct project
n Analysis strategy
n Gathering business requirements
n Requirements definition use cases
n Process modeling
n Data modeling
n Design selection
n Architecture design
n Interface design
n Data storage design
n Program design
¨ Program building
¨ Program and system testing
¨ Conversion strategy
¨ Training plan
¨ Support plan
Processes and Deliverables
n An opportunity to create business value from using information technology initiates a project.
n Feasibility analysis helps determine whether or not to proceed with the IS project.
n Projects are selected based on business needs and project risks.
n The project sponsor is a key person who identifies business value to be gained from using information technology.
n The approval committee reviews system requests from groups throughout the organization and selects projects for the benefit of the business.
IDENTIFYING PROJECTS WITH BUSINESS VALUE
How Do Projects Begin?
n Business needs should drive projects.
n Project sponsor recognizes business need for new system and desires to see it implemented.
n Business needs determine the system’s functionality (what it will do).
n The project’s business value should be clear.
n A document describing business reasons for project and system’s expected value.
n Lists project’s key elements
¨ Project sponsor
¨ Business need
¨ Business requirements
¨ Business value
¨ Special issues or constraints
System Request Examples
n Project sponsor – VP of Marketing
n Business need – Reach new customers and improve service to existing customers
n Business requirements – Provide web-based shopping capability
n Business value – $750,000 in new customer sales; $1.8M in existing customer sales
n Special issues or constraints – System must be operational by holiday shopping season
Preliminary Project Acceptance
n System request is reviewed by approval committee
n Based on information provided, project merits are assessed.
n Worthy projects are accepted and undergo additional investigation – the feasibility analysis.
n Detailed business case for the project
¨ Technical feasibility
¨ Economic feasibility
¨ Organizational feasibility
n Compiled into a feasibility study
n Feasibility is reassessed throughout the project
Can We Build It?
n Users’ and analysts’ familiarity with the business application area
n Familiarity with technology
¨ Have we used it before? How new is it?
n Project size
¨ Number of people, time, and features
n Compatibility with existing systems
Should We Build It?
n Identify costs and benefits
n Assign values to costs and benefits
n Determine cash flow
n Assess financial viability
¨ Net present value (NPV)
¨ Return on investment (ROI)
¨ Break even point(BEP)
Assign Cost and Benefit Values
n Difficult, but essential to estimate
n Work with people who are most familiar with the area to develop estimates
n Intangibles should also be quantified
n If intangibles cannot be quantified, list and include as part of supporting material
If we build it, will they come?
n Strategic alignment
¨ How well do the project goals align with business objectives?
n Stakeholder analysis
¨ Project champion(s)
¨ Organizational management
¨ System users
Approval committee works from the system request and the feasibility study
¨ Project portfolio – how does the project fit within the entire portfolio of projects?
¨ Trade-offs must be made to select projects that will form a balanced project portfolio
¨ Viable projects may be rejected or deferred because of project portfolio issues.
n Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality.
n A project manager has the primary responsibility for managing the hundreds of tasks and roles that need to be carefully coordinated.
Four Key Steps in Managing Projects
n Identifying project size
n Creating and managing the workplan
n Staffing the project
n Coordinating and controlling project activities
Identifying Project Size
Project Manager’s Balancing Act
n The process of assigning projected values for time and effort
n Sources of estimates
¨ Methodology in use
¨ Actual previous projects
¨ Experienced developers
n Estimates begin as a range and become more specific as the project progresses
Project Estimates Based on Industry Standard Percentages
Creating The Workplan
A Workplan Example
¨ Using standard list of tasks
n Top-down approach
¨ Identify highest level tasks
¨ Break them into increasingly smaller units
¨ Organize into work breakdown structure
n List of all tasks in the work breakdown structure, plus
¨ Duration of task
¨ Current task status
¨ Task dependencies
¨ Key milestone dates
Tracking Project Tasks
n Gantt Chart
¨ Bar chart format
¨ Useful to monitor project status at any point in time
n PERT Chart
¨ Flowchart format
¨ Illustrate task dependencies and critical path
Tracking Tasks Using Gantt Chart
Tracking Tasks Using PERT Chart
Staffing The Project
n Staffing levels will change over a project’s lifetime
n Adding staff may add more overhead than additional labor
n Using teams of 8-10 reporting in a hierarchical structure can reduce complexity
Increasing Complexity with Larger Teams
Controlling Project Activities
¨ Formal rules for naming files
¨ Forms indicating goals reached
¨ Programming guidelines
n Project binder
n Table of contents
n Continual updating
n Risk assessment
n Actions to reduce risk
n Revised assessment
n Overly optimistic schedule
n Failing to monitor schedule
n Failing to update schedule
n Adding people to a late project
n The As-Is system is the current system and may or may not be computerized
n The To-Be system is the new system that is based on updated requirements
n The System Proposal is the key deliverable from the Analysis Phase
n The goal of the analysis phase is to truly understand the requirements of the new system and develop a system that addresses them — or decide a new system isn’t needed.
n The System Proposal is presented to the approval committee via a system walk-through.
n Systems analysis incorporates initial systems design.
n Requirements determination is the single most critical step of the entire SDLC.
What is a Requirement?
n A statement of what the system must do
n A statement of characteristics the system must have
n Focus is on business user needs during analysis phase
n Requirements will change over time as project moves from analysis to design to implementation
n Functional Requirements
¨ A process the system hast to perform
¨ Information the system must contain
n Nonfunctional Requirements
¨ Behavioral properties the system must have
n Cultural and political
n Requirements definition report
¨ Text document listing requirements in outline form
¨ Priorities may be included
n Key purpose is to define the project scope: what is and is not to be included.
Basic Steps of Determining Requirements
n Understand the “As-Is” system
n Identify improvement opportunities
n Develop the “To-Be” system concept
n Techniques vary in amount of change
¨ Business Process Automation (BPA) – small change
¨ Business Process Improvement (BPI) – moderate change
¨ Business Process Reengineering (BPR) – significant change
n Additional information gathering techniques are needed as well