BUSINESS IT 3

GROUP 4

MEMBERS:

Edralyn Olaver

Edma Glory Macadaag

Thea Laveros

Shehanie Faith Pableo

Jeseriel Namion

MTH 2:30-4:00

513F

March 4, 2019
 SYSTEM TOOLS AND DOCUMENTATION
Documentation is an important tool to understand how systems work. Accountants
pursue documentation to determine if a proposed system meets the needs of its users
in the organization.
1. DATA FLOW DIAGRAM(DFD)
Data flow diagrams depict the broadest possible overview of system inputs, processes
and outputs. It graphically characterize data processes and flows in a business system.

 Data Flow Approach

Data flow approach emphasizes the logic underlying the system. By using combinations
of only four symbols, the systems analyst can create a pictorial depiction of processes
that will eventually provide solid system foundation.
Four basic symbols are used to chart movement on data flow diagrams:
A. DOUBLE SQUARE
This is used to depict an external entity (another department, a business, a person or a
machine) that can send data to or receive data from the system. Each entity is labeled
with an appropriate name(noun). Although it acts with the system it is considered as
outside of the boundaries of the system. The same entity may be used more than once
on the same data flow diagram, to avoid crossing data flow line.
B. ARROW
The arrow shows movements of data from one point to another, with the head of the
arrow pointing towards the data’s destination. Data flows occurring simultaneously can
be depicted doing just that through the use of parallel arrows. Since an arrow
represents data about a person, place or thing, it should be described with a noun.
C. RECTANGLE WITH ROUNDED CORNERS
This is used to show the occurrence of a transformation process. Processes always
denote a change in or transformation of data; hence, the data leaving a process is
always labeled differently from the one entering it. Processes represents work being
performed within the system and should be named using one of the following formats.
D. RECTANGLE
These symbols are drawn only wide enough to allow identifying lettering in the
rectangle. In logical data flow diagrams, the type of physical storage (e.g., tape,
diskette, cd) is not specified. At this point the data store symbol is simply showing a
depository that allows addition and retrieval of data The data store may represent a
manual store, such as a filing cabinet, or a computerized file or database.

RULES FOR DRAWING DATA FLOW DIAGRAMS

 Data Flow should not split into two or more different data flows.
 All data flows must EITHER originate or terminate at a process
 Processes needs to have at least one input data flow and one output data flow
2. FLOWCHARTING
Probably the most common systems technique A symbolic diagram that shows the data
flows and sequence of operations in a system. Flowcharts use a standard set of
symbols to describe the transaction processing procedures: The applicable standards
for flowcharting symbols were established by the International Organization for
Standardization (ISO) and the American National Standards Institute (ANSI).
The most common flowcharting systems from the ANSI Bulletin are four groups of
symbols:
o Basic symbols
o Input/output symbols
o Processing symbols
o Additional symbols

Flowchart symbols in EXCEL

A. System Flowchart
A graphical description of the relationship among the input, processing, and output in
an information system. It typically depicts the electronic flow of data and processing
steps in an AIS.
B. Program Flowchart
A graphical description of the sequence of logical operations performed by a
computer in executing a program.
C. Document flowchart
A graphical description of the flow of documents between Dept. within a company.It
concentrates on the physical flow of reports and documents.
D. Analytic Flowchart
An analytic flowchart identifies all significant processing in an application, emphasizing
processing tasks that apply controls. The flow of processing is depicted using symbols
connected with flowlines.
E. Forms Distribution Flowchart
A forms distribution chart shows the distribution of multiple copy forms within an
organization. The emphasis is on who gets what forms rather than on how these forms
are processed.

SYSTEMS PLANNING
Business Systems Planning (BSP) is a method of analyzing, defining and designing
the information architecture of organizations.

PROJECT is a planned series of related activities for achieving a specific business

objective.

PROJECT MANAGEMENT
It refers to the application of knowledge, skills, tools, and techniques to achieve specific
targets within specified budget and time constraints.

Major Variables of Project Management:

1. SCOPE
It defines what work is or is not included in a project.

2. TIME
It is the amount of time required to complete the project.

3. COST
It is based on the time to complete a project multiplied by the cost of human resources
required to complete the project.
 INFORMATION SYSTEM PROJECT COST
This project costs Includes the following:
• Hardware
• Software
• Workplace
4.QUALITY
It is an indicator of how well the end result of a project satisfies the objectives specified
by the management.

5 Phases of Project Management

1. Project Initiation
2. Project Planning
3. Project Execution
4. Project Monitoring and Control
5. Project Closure
PROJECT INITIATION
The first phase in project management. It involves starting up a new project.

STARTING A NEW PROJECT

• Defining objectives, scope, purpose and deliverables to be produced.
• Hiring or assigning project team.
• Setting up project office.
• Review the project to gain approval in order to proceed to the next phase.

PROJECT INITIATION STEPS

o Develop a business case.

o Do a feasibility study.
o Establish the project charter.
o Identify stakeholders.
o Appoint Project Team and set up office.
o Review the project and prprepare for the next phase

PROJECT PLANNING
The second phase of project management. A well-written project plan is prepared in this
phase.

THE PROJECT PLAN:

• Gives the team direction for producing quality outputs.
• Handling risk.
• Creating acceptance.
• Communicating benefits to stakeholders and managing suppliers.

PROJECT EXECUTION
This is the phase that is most commonly associated with project management. 

PROJECT MONITORING AND CONTROL

Monitoring and control are sometimes combined with execution because they often
occur at the same time.

PROJECT CLOSURE
Teams close a project when they deliver the finished project to the customer,
communicating completion to stakeholders and releasing resources to other projects.

SYSTEMS ANALYSIS
-is the process of examining a business situation for the purpose of developing a
system solution to a problem or devising improvements to such a situation.
Analysis is the first SDLC phase where we begin to understand, in depth, the
needs for system. System analysis involves a substantial amount of effort and cost and
is therefore undertaken only after management had decided that the systems
development project under consideration has merit and should be pursed through this
phase. Most observers would agree than many of the errors in developed system are
directly traceable to inadequate efforts in the analysis and design phases of the life
cycle. Industry studies show that 56% of systems problems are based on poor
requirements definition, as opposed to 7% that are caused by poor coding. In the
maintenance arena, 82% of the effort is due to poor requirements as opposed to 1% for
poor coding. However, for many reasons, it is difficult to obtain a correct and complete
set of requirements.
Requirements Determination
Requirements determination is the beginning sub phase of analysis. In this sub phase,
analysts should gather information on what the system should do from as many sources
as possible.
Collection of information is at the core of systems analysis. Information requirement
determination (IRD) is frequently and convincingly presented as the most critical phase
of information system (IS) development, and many IS failures have been attributed to
incomplete and inaccurate information requirements.
System analysts must collect the information about the current system and how users
would like to improve their performance with new information system. Accurately
understanding the users’ requirements will help the system developing team deliver a
proper system to the end users in limited time and limited budget.
There are some traditional methods to help collecting system requirements, such as
interviewing, survey, directly observing users, etc. Nowadays, some modern
requirements colleting methods, such as JAD and prototyping, emerged.

 Interviewing
- is one of the primary ways to gather information about an information system. A
good system analyst must be good at interviewing and no project can be conduct
without interviewing. There are many ways to arrange an effectively interview
and no one is superior to others. However, experience analysts commonly
accept some following best practices for an effective interview:
 Prepare the interview carefully, including appointment, priming question,
checklist, agenda, and questions.
 Listen carefully and take note during the interview (tape record if possible).
 Review notes within 48 hours after interview.
 Be neutral.
 Seek diverse views.
 Questionnaires
- have the advantage of gathering information from many people in a relatively
short time and of being less biased in the interpretation of their results. Choosing
right questionnaires respondents and designing effective questionnaires are the
critical issues in this information collection method. People usually are only use a
part of functions of a system, so they are always just familiar with a part of the
system functions or processes. In most situations, one copy of questionnaires
obviously cannot fit to all the users. To conduct an effective survey, the analyst
should group the users properly and design different questionnaires for different
group. Moreover, the ability to build good questionnaires is a skill that improves
with practice and experience. When designing questionnaires, the analyst should
concern the following issues at least:
 The ambiguity of questions.
 Consistence of respondents’ answers.
 What kind of question should be applied, open-ended or close-ended?
 What is the proper length of the questionnaires?
 Directly observing users.
People are not always very reliable informants, even when they try to be
reliable and tell what they think is the truth. People often do not have a
completely accurate appreciation of what they do or how they do it. This I
especially true concerning infrequent events, issues from the past, or issues for
which people have considerable passion. Since people can not always be trusted
to reliably interpret and report their own actions, analyst can supplement and
corroborate what people say by watching what they do or by obtaining relatively
objective measures of how people behave in work situation. However,
observation can cause people to change their normal operation behavior. It will
make the gathered information biased.
 Analyzing procedures and other documents.
By examining existing system and organizational documentation, system
analyst can find out details about current system and the organization these
systems support. In documents analyst can find information, such as problem
with existing systems, opportunities to meet new needs if only certain information
or information processing were available, organizational direction that can
influence information system requirements, and the reason why current systems
are designed as they are, etc.
However, when analyzing those official documentations, analysts should pay
attention to the difference between the systems described on the official
documentations and the practical systems in real world. For the reason of
inadequacies of formal procedures, individual work habits and preferences,
resistance to control, and other factors, the difference between so called formal
system and informal system universally exists.
 Joint Application Design (JAD).
- is a facilitated, team-based approach for defining the requirements for new or
modified information systems. JAD is started at IBM in the late 1970s. The main
idea behind JAD is to bring together the key users, managers, and system
analysts involved in the analysis of a current system. The primary purpose of
 using JAD in the analysis phase is to collect systems requirements
simultaneously from the key people involved with the system. The result is an
intense and structured, but highly effective, process. Having all the key people
together in one place at one time allows analysts to see where there are areas of
agreement and where there are conflicts.
The typical participants in a JAD are: JAD session leader, end users,
business managers, sponsor, system analysts, IS staff, scribe, etc. The JAD
team is a group of from six to sixteen individual who all have a stake in designing
a highquality system. Approximately two thirds of the group members are
functional experts the other one third are systems professionals. JAD sessions
are usually conducted in a location other than the place where the people
involved normally work, and are usually held in special purpose rooms where
participants sit around horseshoe-shaped tables. Involving so many different
kinds of people in one workshop makes how to effectively and efficiently organize
the JAD session a big challenge.
When a JAD is completed, the final result is a set of documents that detail
the workings of the current system related to study of a replacement system.
These requirements definition document generally includes business activity
model and definitions, data model and definition, data input and output
requirements. It may also include interface requirements, screen and report
layouts, ad hoc query specifications, menus, and security requirements. When
used at a later point in the system development life cycle, a JAD session can
also be used to refine a system prototype, develop new job profiles for system
users, or develop an implementation plan.
However, to exploit full potential of JAD, the groupware tools should be
applied in JAD workshop sessions. The use of groupware tools to support the
joint Application Development technique increases the value of this technique
dramatically. When groupware tools are used in an automated JAD workshop,
they greatly facilitate the generation, analysis, and documentation of information.
This is particularly valuable for JAD workshops conducted to define and build
consensus on the requirements for new systems.
 Prototyping.
Prototyping is a means of exploring ideas before you invest in them. Most
system developers believe that the benefits from early usability data are at least
ten times greater than those from late usability data. [19,20] Prototyping allow
system analysts quickly show users the basic requirement into a working version
of the desired information system. After viewing and testing the prototype, the
users usually adjust existing requirements to new ones. The goal with using
prototyping to support requirement determination is to develop concrete
specification for the ultimate system, not to build the ultimate system from
prototyping. Prototyping is most useful for requirements determination when user
requirements are not clear or well understood, one or a few users and other
stakeholders are involved with the system, possible designs are complex and
require concrete form to fully evaluate, communication problems have existed in
the past between users and analysts, and Tools and data are readily available to
rapidly build working systems, etc.
 When adopting prototyping, analysts should concern about the potential
problems about this requirements determination method, such as informal
documentation, ignored subtle but important requirements, etc.
When we choose requirements determination method for a specific project,
there seven characters of them we should consider. They are Information
Richness, Time Required, Expense, Chance for Follow-up and probing,
Confidentiality, Involvement of Subject, Potential Audience. Table 1 concludes
these characters of previously discussed six requirements determination
methods.

CHARACTERIST INTERVIEWI QUESTIONNAI OBSERVATI DOCUME JAD PROTOTYPI

ICS NG RES ON NT NG
ANALYSIS

Information High Medium to low High Low High Medium to

Richness (passive) High
and old

Time Required Low to Can be Low to Dedicated Moderate

Can be moderate extensive moderate period of and can be
extensive time of all extensive
kinds of
involved
people

Expense Can be high Moderate Can be high Low to High High

moderate

Chance for Good Limited Good Limited Good Good

Follow-up and
probing

Confidentiality Interviewee Respondent Observee is Depends All the Usually

is known to can be known to on nature people know each
interviewer unknown interviewer of know each other
document other

Involvement of Interviewee Respondent is Interviewee None, no All kinds Users are

Subject is involved passive, no s may or clear of people involved
and clear may not be commitm are and
committed commitment involved ent involved committed
and and
committed committe
depending d
on whether
 they know if
they are
being
observed

Potential Limited Can be quite Limited Potentially Potentially Limited

Audience numbers, large, but lack numbers biased by biased by numbers; it
but of response and limited which the is difficult to
complete from some can time of document subordinat diffuse or
responses bias results each s were or adapt to
from those kept or intentiona other
interviewed because lly don’t potential
document want to users
not directly
created point out
for this his
purpose superior’s
errors.

SYSTEMS DESIGN
- a process of defining elements of a system like modules, architecture, components
and their interfaces and data for a system based on the specified requirements.
-it is the process of defining, developing and designing systems which satisfies the
specific needs and requirements of a business or organization.
A systemic approach is required for a coherent and well- running system. Bottom-Up or
Top-Down approach is required to take into account all related variables of the system.
A designer uses the modelling languages to express the information and knowledge in a
structure of system that is defined by a consistent set of rules and definitions. The
designs can be defined in graphical or textual modelling languages.
Some of the examples of graphical modelling languages are:
a. Unified Modelling Language (UML): To describe software both structurally and
behaviorally with graphical notation.
b. Flowchart : A schematic or stepwise representation of an algorithm.
c. Business Process Modelling Notation (BPMN): Used for Process Modelling
language.
d. Systems Modelling Language (SysML): Used for systems engineering.

DESIGN METHODS:
1) Architectural design: To describes the views, models, behaviour, and structure of
the system.
2) Logical design: To represent the data flow, inputs and outputs of the system.
Example: ER Diagrams (Entity Relationship Diagrams).
3) Physical design: Defined as a) How users add information to the system and how
the system represents information back to the user. b) How the data is modelled and
stored within the system. c) How data moves through the system, how data is validated,
secured and/or transformed as it flows through and out of the system.

SYSTEM IMPLEMENTATION AND MAINTENANCE

System Implementation

Implementation is a process of ensuring that the information system is

operational. It involves

Constructing a new system from scratch

Constructing a new system from the existing one

Training

Training Systems Operators

End User Training

Training System Operators involves:

Creating troubleshooting lists to identify possible problems and remedies for the,
as well as the names and telephone numbers of individuals to contact when
unexpected or unusual problems arise.

Familiarization with run procedures, which involves working through the sequence
of activities needed to use a new system.

End User Training involves:

How to operate the equipment

Troubleshooting the system problem

Determining whether a problem that arose is caused by the equipment or software

Training Guidelines:

Establishing measurable objectives

Using appropriate training methods

Selecting suitable training sites

Employing understandable training materials

Training Methods:

Instructor-led training - training session could be one-on-one or collaborative. It is

of two types:

Virtual Classroom - trainers must meet the trainees at the same time but are not
required to be at the same place.

Normal Classroom - trainers must meet trainees at the same time and at the
same place.
Self-Paced Training - trainees learn the skills themselves by accessing the courses
at their own convenience. It is of two types:

Multimedia Training - courses are presented in multimedia format and stored in

CD-ROM.

Web-based Training - courses are often presented in hyper media format and
developed to support internet and intranet.

Conversion - a process of migrating from the old system to the new one. It
provides understandable and structured approach to improve the communication
between management and project team.

Conversion Plan - it contains description of all the activities that must occur during
implementation of the new system and put into operation. It anticipates possible
problems and solution to deal with them.

It includes the ff activities:

Name all files for conversions

Identifying the data requirements to develop new files during conversion

Listing all the new documents and procedures that are required

Identifying the controls to be used in each activity

Identifying the responsibility of person for each activity

Verifying conversion schedule

Conversion Methods:

Parallel Conversion

Direct Cutover Conversion

Pilot Approach

Phase-in Method

File Conversion - a process of converting one format into another.

Post-Implementation Evaluation Review (PIER)

PIER is a tool or standard approach for evaluating the outcome of the project and
determine whether the project is producing the expected benefits to the processes,
products or services,

Objectives of PIER:

To determined the success of a project against the projected costs, benefits, and
timeliness.

To identify the opportunities to and additional value to the project.

To determine the strengths and weaknesses of the project and future reference and
appropriate action.

To make recommendation on the future of the project by refining costs estimating

techniques.

Following staff members should be included in the review process:

Project Team and Management

User staff

Strategic Management Staff

External Users

System Maintenance

Maintenance - means restoring something to its original conditions.

Enhancement - means adding, modifying the code to support the changes in user
specifications.

System Maintenance - conforms the system to its original requirements and

enhancement adds to system capability by incorporating new requirements.
Maintenance Types:

Corrective Maintenance - enables user to carry out the repairing and correcting
leftover problems

Adaptive Maintenance - enables user to replace the functions of the programs

Perfective Maintenance - enables user to modify or enhance that programs

according to the users’ requirements and changing needs.