CIS 2303 – FWA 2020

REVISION for chapters 1, 2, 4, 5 , 8, 9, 11

All the best

Saoud Karam H00387241

Special thanks to CIS Team for helping me

do this revision
 Chapter 1

Impact of IT on business strategies: (slide 6)

- increase employee productivity

- deliver quality products and services
- maintain customer loyalty, and make sound decisions
- Information technology is used to deliver information
- Information technology can mean the difference between success and failure

What is IT (Information Technology)? (slide 7)

- Is a combination of hardware and software products and services that companies use to manage, access,
communicate, and share information.

What is IS (Information System)? (slide 8 -11)

- An information system combines information technology, people, and data to support business
requirements.

Information Systems has five key components:

.‫ اللي باألحمر شرح حق كل كومبوننت‬#

o Hardware )Is the physical layer of the information system(

o Software (System software , application software)

o Data (1. Data is the raw material that an information system transforms into useful information.
2. Tables store data in a database.
3. Linked tables work together to supply data to users.)

o Processes (Describe the tasks and business functions that users, managers, and IT staff members perform to
achieve specific results)

o People (Stakeholders such as customers, managers // Users, or end users of systems)

What is System analysis and design? (slide 12 -13)

- Is a step-by-step process used by organizations for developing high-quality information systems

- Various IT professionals are involved in the development of Information Systems

THE SYSTEMS ANALYST is an IT professional with key responsibilities: (slide 14)

• A systems analyst investigates, analyzes, designs, develops, installs,

evaluates, and maintains a company’s information systems.
• To perform those tasks, a systems analyst constantly interacts with users and managers within and outside
the company.
• On large projects, the analyst works as a member of an IT department team; on smaller assignments, he or
she might work alone.
• Smaller companies often use consultants to perform systems analysis work on an as-needed basis.
Tasks Performed by the Systems Analyst: (slide 15-20)

Defining Requirement:

Prioritizing Requirements

Gathering Facts, data and opinions of Users

Evaluation and Analysis

Drawing Specifications

.‫ الحين بنشرح كل تاسك بروحه‬#

Defining requirement:

- The basic step for any system analyst is to understand the requirements of the users. This is achieved by
various fact-finding techniques like: (interviewing, observation, questionnaire)

Prioritizing requirement:

- Number of users use the system in the organization, and each one has a different requirement and retrieves
different information.
- Due to certain limitations in computing capacity it may not be possible to satisfy the needs of all the users.
- Hence it is important to create list of priorities according to users requirements.

Gathering Facts, data and opinions of Users:

- After determining the necessary needs and collecting useful information, the analyst starts the development
of the system with active cooperation from the users of the system.
- Time to time, the users update the analyst with the necessary information for developing the system.
- The analyst while developing the system continuously consults the users and acquires their views and
opinions.

Evaluation and analysis:

- The analyst must constantly change and modify the system to make it better and more user friendly for the
users

Drawing specifications:

- The analyst must draw certain specifications which will be useful for the manager.
- The analyst should lay the specification which can be easily understood by the manager and they should be
purely non-technical.
- The specifications must be in detailed and in well presented form
Systems Development Methods: (slide 21)

- Structured Analysis
- Agile/SCRUM methods
- Object-Oriented Analysis (OOA)

Overview of AGILE / SCRUM Analysis:

Agile Methodologies share three key principles: (slide 23-29)

- It focus on adaptive rather than predictive methodologies.

- It focus on people rather than roles.
- It focus on self-adaptive processes.

When to use Agile/Scrum?

- If a project is less risky, smaller, and simpler development efforts lend themselves more to Agile methods.
Other determining factors include organizational practice and standards, and the extent to which different
parts of the system will be contracted out to others for development.

Major AGILE Methodologies:

- Agile Scrum Methodology.

- Lean Software Development.

- Kanban.

- Extreme Programming (XP)

- Crystal.

- Dynamic Systems Development Method (DSDM)

- Feature Driven Development (FDD)

Agile LC
THE AGILE PROCESS FLOW:

1. Concept - Projects are envisioned and prioritized

2. Inception - Team members are identified, funding is put in place, and initial environments and
requirements are discussed

3. Iteration/Construction - The development team works to deliver working software based on iteration
requirements and feedback

4. Release - QA (Quality Assurance) testing, internal and external training, documentation development, and
final release of the iteration into production

5. Production - Ongoing support of the software

6. Retirement - End-of-life activities, including customer notification and migration

THE AGILE ITERATION WORKFLOW:

1- Requirements - Define the requirements for the iteration based on the product backlog, sprint backlog,
customer and stakeholder feedback

2- Development - Design and develop software based on defined requirements

3- Testing - QA (Quality Assurance) testing, internal and external training, documentation development

4- Delivery - Integrate and deliver the working iteration into production

5- Feedback - Accept customer and stakeholder feedback and work it into the requirements of the next iteration

Structured Analysis

- Structured Analysis is a traditional systems development technique that is time-tested and easy to understand.
- Uses a series of phases called the Water Fall, to plan, analyze, design, implement, and support an information
system.
- It is called a Predictive approach because systems are developed based on a plan
- It is called a process-centered technique because process models are used to describe processes that change
data into information

Phases of the Waterfall MODEL

Preliminary

Investigation

Report
Systems planning

- Systems request is received and evaluated

- Purpose of this phase is to perform a preliminary investigation whose key part is a feasibility study

Systems Analysis
System
- The purpose is to build a logical model of the new system. Requirements
- The first step is requirements modeling, where you investigate business processes and document
what the new system must do to satisfy users. Document

- Deliverable is the System requirements document which describes management and user
requirements, costs and benefits, and outlines alternative development strategies.

Systems Design System

Design
- The purpose is to create a physical model that will satisfy all documented requirements for the
system. Specs
- At this stage, you design the user interface and identify necessary outputs, inputs, and processes
- Deliverable is system design specification
- Management and user involvement is critical

Systems Implementation

Functional
- New system is constructed
- Programs are written, tested, and documented, and the system is installed IS
- The objective is to deliver a completely functioning and documented information system
- Final preparations include converting data to the new system's files and training users
- This stage also includes an assessment, called a systems evaluation

Systems Operation, Support, and Security

- System goes into operation

- A well-designed system must be secure, reliable, maintainable, and scalable( Operational
- After several years of operation, systems need extensive changes
- During this phase, the IT staff maintains, enhances, and protects the system IS
- Security controls safeguard the system from both external and internal threats
- Most information systems need to be updated significantly or replaced after several years of operation
 Chapter 2

What is a Systems Request?

(The Systems Request is the starting point for a project. It is formal way for asking for IT support or
improvements)

Some of the main reasons for systems requests are?

Improved services || Reduce costs || Stronger Control || More information || Support for new products and
services || Better performance

What is a Business Case?

(The term business case refers to the reasons, or justification, for a proposal or a request)

- A strong business case means that a proposal will add substantial value to the organization and support the
organization’s strategic plan
- Systems development typically starts with a systems request, followed by a preliminary investigation, which
includes a feasibility study

Business Case description?

- Should be comprehensive, yet easy to understand

- Should describe the project clearly, provide the justification to proceed, and estimate the project’s financial
impact
- Should answer questions like the following:
◦ Why are we doing this project?
◦ What is the project about?
◦ How does this solution address key business issues?
◦ How much will it cost and how long will it take?
◦ Will we suffer a productivity loss during the transition?
◦ What is the return on investment and payback period?
◦ What are the risks of doing the project? What are the risks of not doing the project?
◦ How will we measure success?

What is strategic plan?

(A strategic plan is like a roadmap for the future.)

- Without a long-range plan, it’s hard to know if you’re heading in the right direction.
- The plan starts with mission statement, which reflects the company’s purpose, vision, and values.
- SWOT analysis contributes to the strategic planning process by identifying technical, human, and financial
resources.
What is SWOT Analysis?
(During strategic planning, top managers ask a series of questions that is called a SWOT analysis)

- it examines the following:

◦ Strengths (S)
◦ Weaknesses (W)
◦ Opportunities (O)
◦ And Threats (T)
Evaluation of system request:
Who are responsible of the evaluation? Systems review committee or a computer resources committee

Systems Requests Forms

- A properly designed form streamlines the request process and ensures consistency
- Occasionally a situation will arise that requires an immediate response
Systems Review Committees
- Most large companies use a systems review committee to evaluate systems requests
- Many smaller companies rely on one person to evaluate systems requests instead of a committee
- The goal is to evaluate the requests and set priorities
What is Feasibility study?
(Feasibility Study is the assessment or evaluation of a request)

A systems request is evaluated in four areas, what are they?

Economic feasibility
(Is the assessment of Total cost of ownership (TCO) and Benefits)

Operational feasibility
(Is the assessment of operational issues, skills of users, support from management, laws and ethical issues)

Schedule feasibility
(Is the assessment of time needed to develop a solution)

Technical feasibility
(Is the assessment of technical resources)

Objective of Feasibility study?

To determine if it is worthwhile to proceed with a request.

‫ الحين شرح كل وحده‬#

Operational feasibility
Study evaluates if the proposed system will be used effectively after it has been developed. If users have difficulty
with a new system, it will not produce the expected benefits.

Operational feasibility depends on several vital issues:

❖ Users’ ability to use the proposed information systems. Training may be necessary.
❖ Management support to implement system
❖ Impact on the working environment
❖ Legal or Ethical issues

Technical feasibility
Refers to the technical resources needed to develop, purchase, install, or operate the system.
When assessing technical feasibility.

Analyst must consider the following points:

❖ Technical expertise
❖ Compatibility with existing technology
❖ Scalability
❖ Reliability
❖ Performance
Economic feasibility
means that the projected benefits of the proposed system outweigh the estimated costs usually considered the
total cost of ownership (TCO), which includes ongoing support and maintenance costs, as well as acquisition costs.

To determine TCO, the analyst must estimate costs in each of the following areas:
◦ People, including IT staff and users
◦ Hardware and equipment
◦ Software, including in-house development as well as purchases from vendors
◦ Formal and informal training
 ◦ Licenses and fees
◦ Consulting expenses
◦ Facility costs
◦ The estimated cost of not developing the system or postponing the project

Tangible benefits
are benefits that can be measured in dollars. Tangible benefits result from a decrease in expenses, an increase in
revenues, or both.
◦ Eg. Reduction in employees or overtime, reduction in
Intangible benefits
are advantages that are difficult to measure in dollars but are important to the company.
◦ Eg: System that improves employee productivity and customer satisfaction or reputation of the
company
When benefits from implementing a system are higher than TCO then the request is economically feasible.

Schedule feasibility
means that a project can be implemented in an acceptable time frame. When assessing schedule feasibility, a
systems analyst must consider the interaction between time and costs. For example, speeding up a project
schedule might make a project feasible, but much more expensive.

Other issues that relate to schedule feasibility include the following:

◦ Can the company or the IT team control the factors that affect schedule feasibility?
◦ Has management established a firm timetable for the project?
◦ What conditions must be satisfied during the development of the system?
◦ Will an accelerated schedule pose any risks? If so, are the risks acceptable?
◦ Will project management techniques be available to coordinate and control the project?
◦ Will a project manager be appointed?
Preliminary Investigation Overview

A Systems Analyst conducts a Preliminary investigation to study the systems request and recommend
specific action, depends on the nature of the request, the size of the project, and the degree of urgency.

1. Understand the Problem or Opportunity:

• A popular technique for investigating causes and effects is called a fishbone diagram, or
Ishikawa diagram. This helps with root cause analysis
2. Define the Project Scope and Constraints
Project scope , Project creep
Constraint:
Constraints can be:
1= Present versus future, 2= Internal versus external, 3= Mandatory versus desirable
3. Perform Fact-Finding
• During Fact-Finding, you might analyze:
i. Analyze Organization Charts
• Obtain organization charts to understand how the department functions
and identify individuals you might want to interview
ii. Conduct interviews
iii. Review documentation
iv. Observe operations
v. Conduct a user survey
4. Analyze Project Usability, Cost, Benefit, and Schedule Data
 • Before you can evaluate feasibility, you must analyze this data carefully
• What information must you obtain? and how will you gather and analyze the information?
• What sources of information will you use? and what difficulties will you encounter in
obtaining information?
5. Evaluate Feasibility
• Start by reviewing the answers to the questions you asked.
i. Operational feasibility
ii. Technical feasibility
iii. Economic feasibility
iv. Schedule feasibility
6. Present Results and Recommendations to Management
• The final task in the preliminary investigation is to prepare a report to management.
• The format of the preliminary investigation report varies from one company to another.
 Chapter 4

Systems analysis:
( is the second of five phases in the systems development life cycle.)

The various processes in this phase include:

◦ Identify systems requirements using fact finding techniques

◦ Prepare logical models based on the data that is gathered

◦ Find alternative solutions

◦ Suggest various development strategies for the new system, and a plan for the transition to
systems design tasks. Agile or JAD strategies could be used

The deliverable for this phase is the system requirements document.

Systems Requirements (is what must be included in order for the system to be acceptable to users.)

Fact-finding techniques (are used to identify system requirements)

A Systems Requirements Checklist is produced describing the requirements in the following categories

◦ Inputs (Refer to necessary data that enters the system, either manually or in an automated
manner)

◦ Outputs (Refer to electronic or printed information produced by the system)

◦ Processes (Refers to activities and logical rules that are applied to transform the data into
meaningful information || Receiving, validating and saving data, computing totals, sorting and
printing)

◦ Performance (Refer to system characteristics such as speed, volume, capacity, availability, and
reliability)

◦ Controls (The system must provide logon security at the operating system level and at the
application level)

Functional requirements (describe activities or processes the system must perform. Can also include
business logic or rules following that are applied)

Technical requirements (describe an operating environment or a performance objective)

Scalability

Why?:

◦ A scalable system offers a better return on the initial investment

◦ To evaluate scalability, you need information about projected future volume for all outputs,
inputs, and processes
 - Based on requirements TCO (Total Cost of Ownership) is calculated
 TCO includes

◦ Hardware costs

◦ Software development costs

◦ Implementation costs

◦ Other expenses such as maintenance on hardware purchased for the system

Models detailing the current system

◦ Functional Decomposition Diagrams

◦ Data Flow Diagrams

◦ Flowcharts

◦ Process Charts

Solution meeting the requirements is suggested. There can be more than one type of solution

Make or Buy Decision

◦ The choice between developing versus purchasing software often is called a make or buy, or build
or buy decision.

◦ The company’s IT department makes, builds, and develops in-house solution.

◦ A solution can also be purchased from an external solutions provider

Fact-Finding techniques

◦ Face to face Interviews

◦ Focus Groups

◦ Document Review

◦ Questionnaires and Surveys

◦ Observation

◦ Research

◦ Sampling
Interviews

Step 1: Determine the People to Interview

 Informal structures

Step 2: Establish Objectives for the Interview

 Determine the general areas to be discussed

 List the facts you want to gather

Step 3: Develop Interview Questions

 Creating a standard list of interview questions?? helps to keep you on track and avoid
unnecessary tangents

 Avoid leading questions

 Open-ended questions

 Closed-ended questions

 Range-of-response questions

Step 4: Prepare for the Interview

 Careful preparation is essential because an interview is an important meeting and not

just a casual chat

 Limit the interview to no more than one hour

 Send a list of topics

Step 5: Conduct the Interview

 Develop a specific plan for the meeting

Step 6: Document the Interview

 Note taking should be kept to a minimum

 Note date, time, location, purpose of the interview, and the main points you discussed
so the interviewee has a written summary and can offer additions or corrections

Step 7: Evaluate the Interview

 In addition to recording the facts obtained in an interview, try to identify any possible
biases

Other Fact-Finding Techniques

Document Review
Observation

– Seeing the system in action gives you additional perspective and a better understanding
of the system procedures

Questionnaires and Surveys

– When designing a questionnaire, the most important rule of all is to make sure that your
questions collect the right data in a form that you can use to further your fact-finding

– Fill-in form

Sampling

– Systematic sample

– Stratified sample

– Random sample

Main objective of a sample is to ensure that it represents the overall population accurately

Research

◦ Can include the Internet, IT magazines, and books to obtain background information,
technical material, and news about industry trends and developments

◦ Site visit

What is the difference between Interviews and Questionnaires??

◦ Interview is more familiar and personal

◦ Questionnaire gives many people the opportunity to provide input and suggestions

◦ Brainstorming
 Chapter 5
logical model physical model
shows what the system must do, regardless of is built that describes how the system will be
how it will be implemented physically. constructed.

___________________________________________________________________________________

FDD
Functional decomposition diagram (FDD) is: A top down representation of a business process

Drawn like an organization Chart

Business functions or processes are broken down to lower level processes

or functions

During application development, these processes become program modules

_____________________________________________________________________________________

The Unified Modeling Language (UML) is a widely used method of visualizing and documenting
software systems design. UML uses object-oriented design concepts, but it is independent of any
specific programming language and can be used to describe business processes and requirements
generally.

UML provides various graphical tools, such as use case diagrams

Actor: Symbol for a Use Case is an oval with a label that describes the action or event

DFD

A data flow diagram (DFD) shows how data moves through an information system but
does not show program logic or processing steps.

A set of DFDs provides a logical model that shows what the system does, not how it
does it.

That distinction is important because focusing on implementation issues at this point

would restrict your search for the most effective system design.

____________________________________________________________________________
 Process

 Receives input data and produces output that has a different content, form, or
both

 Contain the business logic, also called business rules

Referred to as a black box

____________________________________________________________________

Data Flow

 Represents one or more data items

 The symbol for a data flow is a line with a single or double arrowhead

Three data flow and process combinations that you must avoid:

1- Spontaneous generation ( The APPLY INSURANCE PREMIUM

process, for instance, produces output, but has no input data flow.
Because it has no input, the process is called a spontaneous
generation process.)
2- Black hole ( The CALCULATE GROSS PAY is called a black hole process, which is a
process that has input, but produces no output.)

3- Gray hole ( is a process that has at least one input and one output, but the input obviously is
insufficient to generate the output shown. For example, a date of birth input is not sufficient to
produce a final grade output in the CALCULATE GRADE process)

_____________________________________________________________________

The Data Store

 Represent data that the system stores

 The physical characteristics of a data store are unimportant

because you are concerned only with a logical model

 A data store must be connected to a process with a data flow.

In each case, the data store has at least one incoming and one
outgoing data flow and is connected to a process symbol with
a data flow. ‫هالنقطه فهم‬
 Entity

 Name of the entity appears inside the symbol

 Terminators

 Source

 Sink

DFD entities also are called terminators because they are data origins
or final destinations. Systems analysts call an entity that supplies data to the system a source, and an
entity that receives data from the system a sink.

_____________________________________________________________________-

The first step in constructing a set of DFDs is to draw a context diagram.

1- A context diagram is a top-level view of an information system that shows the system’s
boundaries and scope.
- How do you know which entities and data flows to place in the context diagram?
You begin by reviewing the system requirements to identify all external data sources
and destinations. During that process, you identify the entities, the name and content
of the data flows, and the direction of the data flows. If you do that carefully, and you
did a good job of fact-finding in the previous stage, you should have no difficulty
drawing the context diagram.
Process start with ( process 0)

2- To show the detail inside the black box, you create DFD diagram 0. Diagram 0 (the
numeral zero, and not the letter O) zooms in on the system and shows major internal
processes, data flows, and data stores.
- diagram 0 is an exploded version of process 0, it shows considerably more detail
than the context diagram. You also can refer to diagram 0 as a partitioned or
decomposed view of process 0. When you explode a DFD, the higher-level diagram
is called the parent diagram, and the lower-level diagram is referred to as the child
diagram.

3- Draw the Lower-Level Diagrams

- To create lower-level diagrams, you must use leveling and balancing techniques.
Leveling is the process of drawing a series of increasingly detailed diagrams, until all
functional primitives are identified.
- Balancing maintains consistency among a set of DFDs by ensuring that input
and output data flows align properly.
Balancing ensures that the input and output data flows of the parent DFD are
maintained on the child DFD
Guidelines for Drawing DFDs ‫المبادي لرسم فهم مب حفظ‬

 Draw the context diagram so that it fits on one page

 Use the name of the information system as the process name in the context diagram

 Use unique names within each set of symbols

 Do not cross lines

 Provide a unique name and reference number for each process

 Obtain as much user input and feedback as possible

 Chapter 8

A process description documents the detail of a functional primitive and represents a specific set of processing
steps and business logic.

Modular design is based on combinations of three logical structures, sometimes called control structures
which serves as the building blocks for the process.
Each logical structure has a single entry and exit point.

 The three structures in Modular design are:

◦ Sequence – Completion of steps in a sequential order
◦ Selection – Completion of steps of one or two process steps based on a test or condition.
◦ Iteration – Completion of a process step that is repeated until a specific condition change.

Standard English
A subset of standard English that describes logical process clearly and accurately.
◦ Must conform to the following rules
 Use only the three building blocks of sequence, selection, and iteration
 Use indentation for readability
 Use a limited vocabulary, including standard terms used in the data dictionary and
specific words that describe the processing rules
◦ Structured English is similar to pseudocode but the primary focus of structured English is to show
the underlying business logic whereas in pseudocode it is more concerned in coding logic.

Decision Tables
◦ Shows a logical structure, with all possible combinations of conditions and resulting actions
◦ It is important to consider every possible outcome to ensure that you have overlooked nothing

How to make a Decision Table?

What if we add another condition to the VERIFY ORDER process?

decision tree

A decision tree is a graphical representation of the conditions, actions, and rules found in a decision table

Example
 Chapter 9
Switchboard is a form with buttons that enable the user to navigate to various forms and reports available in the
application.

Control Features on Pictures

Forms

Menu Bar

Command button

Dialog box

Text box
 List box

Drop down box

(combo box)

radio button

check box

calendar control

Image control
Reports

 Reports are static display of information stored in the database

 Reports can be viewed on screen, printed or downloaded for further processing or transmission

 Reports can be confirmation of a transaction such as bills, invoices, receipts, tickets, student transcripts
etc.

 Reports can be generated to provide information for better decision making

Report Design Considerations

When designing reports the following points must be considered:

1) What is the purpose of the output?

2) Who wants the information, why is it needed, and how will it be used?

3) What specific information will be included?

4) Will the output be printed, viewed on-screen, or both? What type of device will the output go to?

5) When will the information be provided, and how often must it be updated?

6) Do security or confidentiality issues exist?

Report Design

Types of Reports

 A detail report produces one or more lines of output for each record processed

 An exception report displays only those records that meet a specific condition or conditions. Exception
reports are useful when the user wants information only on records that might require action, but does
not need to know the details

 A summary report displays summaries based on selection criteria for users/managers who want to see
total figures and do not need supporting details.

 A graphical report displays summarized data as a chart for better understanding

 Detail Report Exception Report

Summary Report Graphical Reports

 Chapter 11
Phase Description

Systems Implementation

- is the fourth phase in the systems development life cycle.

- It includes solution development/building, documentation, testing, training, data
conversion, and the system changeover.
- The deliverable for this phase is a completely functioning information system
Steps in systems implementation are:

- Build and test the new system

- Provide training for users, managers, and IT staff.

- Perform data conversion and system changeover.

- Carry out post-implementation evaluation/feedback of the system.

- Present a final report to management.

Before a changeover can occur, the new system that is developed must be

1- built
2- tested

3- documented carefully,

4- users must be trained,

5- existing data must be converted to the new system.

6- The old system should cease, and the new system must be operational

Building the system

Activities include

- Purchase hardware and software

- Build database
- Write code or build the application
- Ensure quality: product must match requirements, must be functional and must be
without errors
Testing

After the system is built it must be tested.

• Test Plan is created which will include details (like who is responsible and what test data will be
used) → Example of details

• Test data is created. Test data includes correct data and incorrect data
 • Programs are tested with test data ?? to ensure that correct output is generated

Testing relevant to applications:

Types of tests are:

- Unit Testing – each program/page/module is tested for interface design, syntax and
logical errors. Each program should retrieve and save data without errors
- Integration Testing – is testing programs that depend on each other. This test ensures
that data that is passed by one program to another is correct
- System Testing – all programs/modules/pages in a system are tested.

Testing Networks

Conduct various tests such as

- hardware tests
- Routing tests
- Traffic tests
- Security tests
Scenarios and prototypes and testing tools are used to
test performance of networks.

Documentation

describes an information system and helps the users, managers, and IT staff who must interact with it.
Different types of documentation:

- Program Documentation
is written for programmers to describe the input data, output and processing logic

- System Documentation
includes all the documentation relating to the system. Includes systems requests, reports,
all the design documents such as the data and process models

- Operations Documentation
Is documentation about how to use the system and is usually for IT professionals who
will be responsible for operating the system

- User Documentation
Systems analysts usually are responsible for preparing documentation to help users learn
the system.
Management Approval

- After documentation and system testing is complete, then the system is presented to the
management for approval.
- If system testing produced no technical, economical, or operational problems, then
management determines a schedule for system installation and evaluation.
Training

What is the purpose of training?

- To prepare users to use the new system effectively.

Training can include:

- training on hardware, software and understanding of new processes

Where can training can be conducted?

- on-site or outside the organization.

Format of training depends on the needs of the organization and skills of users

Outside Training Resources:

- Many training consultants, institutes, and firms are available that provide either
standardized or customized training packages.
Vendor Training: ‫التدريب من البائع‬

- If the new system includes the purchase of software or hardware, then vendor-supplied
training is a good option
)Example if the new system includes the new hardware such as a barcode scanner or a mobile device suppliers/vendor
can provide the training( → ‫هذا مثال‬

To enable users to learn at a time most convenient to them, the following can be made available

- Webinars
- Webcasts and Podcasts,
- Online interactive Tutorials on using the software
Training Tips:

- Train people in groups, with separate training programs for distinct groups.

- Select the most effective place to conduct the training.

- Provide for learning by hearing, seeing, and doing.

- Prepare effective training materials, including interactive tutorials.

- Rely on previous trainees.

Interactive Training:

- Usually, a relationship exists between training methods and costs.

- Online training (Should include step-by-step instructions.)
- Video tutorials (You don’t have to be a professional video developer to create effective
training tutorials.)

Data Conversion:

This is a process used to load existing data into the new system.

- Conversion depends on how data is currently stored and the requirement for the new
system
(For example the current system may store data in manual files/ excel/ Access/ Ms SQl
files and the new system may be in Oracle)
Issues to consider

– The old system might be capable of exporting data in an acceptable format to the new
system or in a standard format such as ASCII or ODBC (Open Database Connectivity).

– If a standard format is not available, you must develop a program to extract the data
and convert it.

– Often requires additional data items, which might require manual entry.

Data Conversion Security and Controls

– You must ensure that all system control measures are in place and operational to
protect data from unauthorized access and to help prevent erroneous input.

– Some errors will occur and must be dealt with

– It is essential that the new system be loaded with accurate, error-free data.

System Changeover Strategies:

System changeover is the process of putting the new information

system online and retiring the old system.

Changeover can be rapid or slow, depending on the method used.

Changeover needs resources and creates risks that need to be

managed.

What are system changeover strategies or methods?

- Direct Cutover: Retire the old system and start the new system when it becomes
operational
– Involves more risk

– Companies often choose the direct cutover method

( to implement commercial software packages such as accounting and inventory ) → ‫ها‬
‫سبب ليش الشركات تختاره‬
– Cyclical information systems are usually converted using the direct cutover method at
the beginning of a quarter, calendar year, or fiscal year.

- Parallel Operation: Requires that both the old and the new information systems operate
fully for a specified period.
- Data is input into both systems, and output generated by the new system is
compared with the equivalent output from the old system. When users,
management, and the IT group are satisfied that the new system operates
correctly, the old system is terminated.
- Easier to verify that the new system is working properly under parallel operation
than under the direct cutover method.
- Running both systems is expensive and cause processing delays.
- It is not practical if the old and new systems are incompatible technically.

- Pilot Operation: is a combination of parallel operation and direct cutover methods.

- involves implementing the complete new system at a selected location of the
company
- During pilot operation, the old system continues to operate for the entire
organization, including the pilot site.
- Applies to organizations with many departments/branches. The group who uses
the new system first is called the pilot site.
- The old system continues to operate for the rest of the entire organization.
- After the system proves successful at the pilot site, it is implemented in the rest of
the organization, usually using the direct cutover method.
- Phased Operation: allows you to implement the new system in stages, or modules..
– The risk of errors or failures is limited to the implemented module only.
– Is less expensive than the full parallel operation.
– Is not possible, however, if the system cannot be separated easily into logical
modules or segments.
Post-Implementation Tasks

Post-Implementation Evaluation is necessary to check the quality of the new system. User feedback or
satisfaction is gathered in the following areas

• Accuracy, reliability and completeness of the product

• Hardware performance

• Reliability of security

• Quality of Training

• Documentation

• Professionalism of IT team

Final Report to Management

• Your report should include the following:

• Final versions of all system documentation.

• Planned modifications and enhancements to the system that have been

identified.

• Summary of all actual systems development costs and schedules.

Final Report to Management

• Your report should include the following:

- Comparison of actual costs and schedules to the original estimates.

- Post-implementation evaluation if it has been performed.

• Marks the end of systems development work

All the best

Saoud Karam H00387241

Special thanks to CIS Team for helping me

do this revision