Introduction to systems development and systems analysis ( Topic 8) Flashcards
Why Update Systems?
- User or business changes
- Technology changes
- To improve business process
- Create competitive advantage
- Increase productivity gains
- Integrate multiple systems
- Aging systems need replacement
- Develop quality, error-free software
Systems Development Life Cycle (SDLC)
- Systems analysis
- Conceptual design
- Physical design
- Implementation and conversion
- Operations and maintenance
Systems analysis
First SDlC step where the information needed to purchase, develop, or modify a system is gathered.
Conceptual design
Second SDlC step where analysts decide how to meet user needs, identify and evaluate design alternatives, and develop de- tailed specifications for what the system is to accomplish and how it is to be controlled.
Physical design
Third SDlC step where broad, user-oriented conceptual design requirements are translated into the detailed specifications used to code and test software, design input/ output, create files/databases, develop procedures, and imple- ment controls.
Implementation and conversion
Fourth SDlC step where the company hires and trains employees, tests and modifies procedures, establishes stan- dards and controls, completes documentation, moves to the new system, and detects and corrects design deficiencies.
Operations and Maintenance
Fifth SDlC step where the system is periodically reviewed and necessary modifications and improvements are made.
Who is involved in the SDLC
• Information Systems Steering Committee
– Executive level, plans and oversees IS function; facilitates coordination with integration of systems activities
• Project Development Team
– Plan and monitor project progress
• Programmers
– Write and test programs according to analysts specifications
• Systems Analysts
– Determine information needs, prepare specifications for programmers
• Management
– Get users involved in the process, provide support for development projects, align projects to meet organizations strategic needs
• Users
– Communicate needs to system developers, help design and test to ensure complete and accurate processing of data
Computer Programers
write and test programs using the specifications developed by systems analysts. They also modify and maintain existing computer programs.
System Development Planning
- Proper planning provides for achieving goals and objectives
- For systems development, two plans needed:
– Project Development Plan
Specific to a project and authored by the project team identifies people, hardware, software, and financial resources needed
– MasterPlan
Long-range and authored by steering committee outlining prioritized projects and timetables
Planning Technique
- PERT Chart
Program Evaluation and Review Technique (PERT)
• Network of arrows and nodes representing project activities that require an expenditure of time and resources and completion and initiation of activities.
• Completion time estimates made.
• Critical path—the path requiring the greatest amount of time is determined. ( critical path - The PERT path re- quiring the greatest amount of time to complete a project; if a critical path activity is delayed, the whole project is delayed.)
Planning Technique
- GANTT Chart
A bar chart with project activities on the left-hand side and units of time across the top.
Graphically shows entire schedule for a large, complex project.
Capital Budgeting
- Cost-Benefit Analysis
Benefits and costs estimated and compared to determine whether system is cost beneficial.
Benefits and costs (not easily quantifiable) estimated and included.
If they cannot be accurately estimated, they are listed, and their likelihood and expected impact on the organisation evaluated.
Capital Budgeting
- Techniques
- Payback Period
- Net Present Value (NPV)
- Internal Rate of Return (IRR)
Internal Rate of Return (IRR)
- Effective interest rate that results in an NPV of zero.
* A project’s IRR compared with minimum acceptable rate to determine acceptance or rejection.
Net Present Value (NPV)
- Future benefits discounted back to present.
- Initial cost subtracted
- Positive NPV = economically feasible.
Payback Period
• Number of years required for net savings to equal initial cost of investment.
Behavioural aspects to change: why behavioural problems occur
The positive and negative ways people react to change; manag- ing these behavioral reactionsis crucial to successfully imple- menting a new system.
The best system will fail without the support of the people it serves. Why people resist change:
Fear
- People fear the unknown, losing their jobs, losing respect or status, failure, technology and automation, and the uncertainty accompanying change.
Lack of top management support
Lack of communication
Disruptive nature of change
Methods of instituting change
- Resistance is often a reaction to the methods of instituting change rather than to change itself
Biases and emotions
- People with emotional attachments to their duties or coworkers may not want to change if those elements are affected.
Personal characteristics and background.
- younger and more highly educated people are, the more likely they are to accept change
Types of Resistance to change
Aggression
• Behaviour that destroys, cripples or weakens system effectiveness, such as increased error rates, disruptions or deliberate sabotage.
Projection
• Blaming new system for everything that goes wrong.
Avoidance
• Ignoring a new AIS in the hope that problem (system) will eventually go away.
How to prevent resistance
• Management support
– Provide resources and motivation
• Satisfy user needs
• Involve users
– Participation improves communication and commitment
• Reduce fears, emphasize opportunities
- Users are vitally interested in how system changes affect them personally. Address their concerns and provide assurances (to the extent possible) that job losses and responsibility shifts will not occur
- Avoid emotionalism - Emotional issues should be allowed to cool, they should be handled in a nonconfrontational manner, or they should be sidestepped.
- Provide training
• Performance evaluation
– Reevaluate to ensure performance standards are consistent with the new system
- Keep open communications
- Test the system prior to implementation
• Keep system simple
– Introduce in stages
– Avoid radical changes
• Control user’s expectations
– Be realistic
Phase 1 Systems Analysis
When a new or improved system is needed, a written request for systems development is prepared.
Request for systems development - A written request for a new or improved system that describes the current system’s problems, the reasons for the change, and the proposed system’s objectives, benefits, and costs.
initial investigation - A preliminary investigation to determine whether a proposed new system is both needed and feasible.
proposal to conduct systems analysis - A request to complete the systems analysis phase for a project that makes it through the initial investigation.
systems survey - An extensive study of the current AIS.
Phase 1 Systems Analysis
AIS that has the following objectives:
●Gain an understanding of company operations, policies, procedures, and information flow; AIS strengths and weaknesses; and available hardware, software, and personnel.
●Make preliminary assessments of current and future processing needs, and determine the extent and nature of the changes needed.
●Develop working relationships with users, and build support for the AIS.
●Collect data that identify user needs, conduct a feasibility analysis, and make recommendations to management.
Systems documentation
A complete description of how the system is supposed to work, including questionnaire copies, interview notes, memos, docu- ment copies, and models.
Physical model
The description of how a system functions by describing document flow, computer processes performed, the people performing them, and the equipment used.
Logical model
System description that focuses on what essen- tial activities are performed and the flow of information irrespec- tive of how the flow is actually accomplished.
Systems survey report
A report that summarizes all the activi- ties that took place during the systems survey, including all relevant documentation.
Feasibility study
Information needs and system requirements
The following four strategies are used to determine AIS requirements:
- Ask users what they need. This is the simplest and fastest strategy, but many people do not understand their needs. They know their job but may be unable to break it down into the individual information elements they use
- Analyze external systems. If a solution already exists, do not “reinvent the wheel.”
- Examine existing systems. Determine if existing modules are used as intended, may be augmented by manual tasks, or may be avoided altogether
- Create a prototype. When it is difficult to identify requirements, a developer can quickly rough out a system for users to critique
Systems Analysis Report
Comprehensive report summarizing systems analysis that docu- ments the findings of analysis activities.
Systems Survey
A systems survey involves an extensive study of the current AIS Objectives are:
• Gain a thorough understanding of
- Company operations, policies, and procedures
- Data and information flow
- AIS strengths and weaknesses
- Available hardware, software, and personnel
• Make preliminary assessments of current and future processing needs, and determine extent and nature of needed changes.
• Develop working relationships with users and build support
• Collect data that identify user needs, conduct a feasibility analysis, and make recommendations to management.
Gathering Data on Current System
Four common methods of gathering data are: • Interviews • Questionnaires • Observation • System documentation
There are advantages and disadvantages for each method of data gathering
(review notes)
Systems Documentation
Once data is gathered, document findings and model existing system.
Another form of documentation is a system model.
• Physical models illustrate how a system functions by describing
- Flow of documents (document flowcharts)
- Computer processes performed (system flowcharts)
- People performing them
- Equipment used
- Any other physical elements
• Logical models illustrate what is being done regardless of how the flow is accomplished and flows of data (data flow diagrams, E-R diagrams, REA data models).
Feasibility Study
-Does it make sense to proceed with new system?
Economic
• Will system benefits justify the time, money, and resources required to implement it?
Technical
• Can system be developed and implemented using existing technology?
Legal
• Does system comply with all applicable federal and state laws, administrative agency regulations and contractual obligations?
Scheduling
• Can system be developed and implemented in time allotted?
Operational
• Does organisation have access to people who can design, implement and operate proposed system? Will people use the system?
Identify Information needs and systems requirements
Once project deemed feasible identify information needs of users and document systems requirements.
Strategies are used to determine AIS requirements:
- Ask users what they need
- Analyse external systems
- Examine existing systems
- Create a prototype
Possible contents of system requirements
( read notes )
Systems Analysis Report
Concluding step, prepare systems analysis report.
•Outlines and documents analysis activities.
•Provides recommendations that result from the systems analysis.
Go/no-go decision made up to three times during systems analysis.
- During an initial investigation, to determine whether to conduct a systems survey.
- At the end of a feasibility study, to determine whether to proceed to an information requirements phase.
- At completion of an analysis phase, to decide whether to proceed to conceptual systems design.
Phase 2 Conceptual System Design
Developer creates a general framework for implementing user requirements and solving the problems identified in the analysis phase.
• Evaluate design alternatives.
• Prepare design specifications.
• Prepare conceptual systems design report.
Preparing Design Specifications
- Output -
- How often?
- What should reports contain?
- What should reports look like?
- Should reports be online or hard copy or both?
- Because the system is designed to meet user information needs, output specifica- tions are prepared first. To evaluate store sales, SM must decide (a) how often to produce a sales analysis report, (b) what the report should contain, (c) what it will look like, and (d) whether it is a hard-copy or screen (or both) output.
Preparing Design Specifications
-Data storage-
- What data elements must be stored to produce a report?
- How they should be stored?
- What type of file or database should be used?
Preparing Design Specifications
- Input -
• Where, when, and how to collect the data?
Preparing Design Specifications
-Processing procedures and operations -
Design considerations include how to process the input and stored data to produce the sales report and in which sequence the processes must be performed.
Phase 3 - Physical Design
Conceptual designs are translated into detailed specifications that are used to code and test computer programs. • Output • File and database • Input • Program • Procedures • Controls
Phase 3 - Physical Design
( read notes )
Output Design
• Types of output
Determine nature, format, content, and timing of reports, documents and screen displays.
• Types of output
• - Scheduled reports (pre-specified content; prepared on regular basis, e.g. monthly performance reports)
• - Special-purpose analysis reports (no pre-specified content; non prepared on regular basis, e.g. new product profitability)
• - Triggered exception reports (pre-specified content; prepared in response to abnormal conditions)
• - Demand reports (pre-specified content; prepared on request)
Output Design considerations
( see image document )
File and Database Design Considerations
( see image document )
Input design considerations
( see image document )
Principles of Good form design
( see image document )
Program Design
- Describe and explain requirements
•Determine user needs
- Systems analysts consult with users and reach an agreement on user needs and software requirements.
- Create and document development plan
- Write program instructions (code the system)
- Program preparation time may range froma few days to a few years, depending on program complexity. Programming standards (rules for writing programs) contribute to program consistency, making them easier to read and maintain.
- Computer programs should be subdivided into small, well-defined modules to reduce complexity and enhance reliability and modifiability, a process called structured programming.
•Test program (debug for errors)
Is the process of discovering and eliminating program errors. A program is tested for logic errors using test data that simulate as many real processing situations and input data combinations as possible
•Document program
Documentation explains how programs work and is used to correct errors. Program documentation includes flowcharts, data flow diagrams
•Train users
•Install system
All system components, including the programs and the hardware, are combined, and the company begins to use the system.
•Use and modify system
Factors that require existing programs to be revised, referred to as program maintenance, include requests for new or revised reports; changes in input, file content, or values such as tax rates; error detection; and conversion to new hardware.
Procedures
Procedures for who, what, where, why, when • Input preparation • Transaction processing • Error detection and correction • Controls • Reconciliation of balances • Database access • Output preparation and distribution • Computer operator instructions
physical systems design report
Summarizes what was accom- plished in physical design; used to determine whether or not to proceed to the implementation phase.
Controls Design Considerations
( read image document )
Phase 4 Implementation and Conversion
Process of installing hardware and software and getting AIS up and running. • Planning • Prepare site • Test hardware • Train personnel • Complete documentation • Test system • Conversion
Implementation plan
A written plan showing how the new system will be implemented; specifies when the project should be complete and the iS operational, including a completion timetable, cost estimates, task milestones, and who is responsible for each activity.
Types of Documentation
Development documentation
• A system description; copies of output, input, and file and database layouts; program flowcharts; test results; and user acceptance forms.
Operations documentation
• Includes operating schedules; files and databases accessed; and equipment, security, and file-retention requirements.
User documentation
• Teaches users how to operate AIS; it includes a procedures manual and training materials.
Types of System Testing
Walk-through
• Step-by-step reviews of procedures or program logic to find incorrect logic, errors, omissions or other problems.
Processing test data
• Using both valid transactions and all possible error conditions.
Acceptance tests
• Real transactions and files rather than hypothetical ones, users develop acceptance criteria and make final decision whether to accept AIS.
Types of Conversions
Direct
• Terminates old AIS when the new one is introduced.
- For example, SM could discontinue its old system on Saturday night and use its new AIS on Monday morning. Direct conversion is appropriate when a new system is so different that com- parisons between the two are meaningless. The approach is inexpensive, but it provides no backup AIS.
Parallel
• Operates old and new systems simultaneously for a period.
- SM could process transactions with both systems, compare the output, recon- cile the differences, correct problems, and discontinue the old system after the new sys- tem proves itself. Parallel processing protects companies from errors, but it is costly and stressful to process transactions twice.
Phase-in
• Gradually replaces elements of old AIS with new one.
Phased conversion
Pilot conversion
• Implements a system in one part of organisation, such as a branch location. – isolated location to detech specific errors
• Localises conversion problems and allows training in a live environment.
implements a system in one part of the organization, such as a branch location. For example, SM could install its new POS system at one of its stores using a direct, parallel, or phase-in approach.
postimplementation review
review made after a new sys- tem has been operating for a brief period to ensure that the new system is meeting its planned objectives, identify the adequacy of system standards, and review system controls.
postimplementation review report
a report that analyzes a newly delivered system to determine if the system achieved its intended purpose and was completed within budget.
Phase 5 Operations and Maintenance
• Conduct post-implementation review includes answering these questions:
– Does the system meet the organization’s goals?
– Are user’s satisfied?
– Were expected benefits achieved?
– Were actual costs inline with expected costs?
– Is the system reliable?
– Does the system produce accurate and complete data and on a
timely basis?
– Is the system compatible with existing systems?
– Is the system safeguarded from errors, fraud, and intrusion?
• – Are there adequate error-handling procedures in place?
– Is everyone trained to use the new system?
– Is systems documentation complete and accurate?
