Systems Analysis and Design Manual

Analysis and design of systems 1
CHAPTER
CONCEPTS OF SYSTEMS ANALYSIS.

1.1 ORIGINS OF THE SYSTEMS ANALYST
The first systems analysts emerged in the industrial revolution. They did not work, at first,
with computers or computer-based systems. Instead, they were industrial engineers whose
responsibilities focused on designing effective manufacturing systems. Information
systems analysts emerged in response to the need to improve computing resources to meet
the new information process requirements of business applications.
Despite its enormous present and future technological possibilities, the computer still
owes its power and usefulness to people. It is the people in companies who define the
applications and problems that the computer has to solve .
1.2 SYSTEMS NEED

The field of systems is an integral part of the work of every executive, that is, each person
who supervises, directs or manages the activities of subordinates, regardless of the
number, has in their work an inherent responsibility for the systems, procedures or
methods they employ. him and his subordinates.
The location of work systems and procedures is found in the administrative element of
planning, which is the moment where how things are going to be done are defined.
1.3 GENERAL CONCEPTS OF THE ANALYSIS

It is a set or arrangement of procedures or programs related so that together they form a
single unit. A set of facts, principles and rules classified and arranged in an orderly
manner showing a logical plan in the union of the parts. A sorting method, plan, or
procedure for doing something.
It is also a set or arrangement of elements to achieve a predefined objective in the

processing of Information. This is carried out taking into account certain principles:
• The information domain of a problem must be presented and understood.

• Define the functions that the Software must perform.
• Represent the behavior of the software as a result of external events.
• Hierarchically divide the models that represent information, functions and

behavior.
The process must start from the essential information to the detail of the Implementation.
The role of analysis may be to support the activities of a business, or to develop a product
that can be sold to generate profits. To achieve this objective, a computer-based system
makes use of six (6) fundamental elements:
• Software , which are computer programs, with data structures and their
documentation that make the logistics methodology or requirements controls of
the Program effective.
• Hardware , electronic and electromechanical devices, that provide fast, accurate

and effective calculation capacity and functions (Computers, Censors, machinery,
pumps, readers, etc.), that provide an external function within the Systems.
• Personal , are the operators or direct users of the System tools.
• Database , a large collection of information organized and linked to the System

that is accessed through the Software.
• Documentation, Manuals, forms , and other descriptive information that details

or gives instructions on the use and operation of the Program.
• Procedures, or steps that define the specific use of each of the elements or
components of the System and the rules for its management and maintenance.
A System Analysis is carried out taking into account the following objectives:
• Identify the Client's needs.
• Evaluate what concepts the client has of the system to establish its viability.
• Perform a Technical and economic Analysis.
• Assign functions to Hardware, Software, personnel, database, and other elements

of the System.
• Establish budget and time planning constraints.
• Create a system definition that forms the foundation for all engineering work.
1.4 SYSTEMS CLASSIFICATION

The systems are classified into:
Natural systems and systems created or made by man. Public and private organizations
constitute systems created or made by man.
Considering the number and complexity of the elements and their relationships, and the
possibility of predicting their behavior, systems can be simple, complex and very complex;
and determinists and probabilists.
Another classification of systems distinguishes closed systems from open systems. The vast
majority of organic systems are open, this means that there is an exchange of energy with
their members.
Mechanical or non-living systems and living systems. Easy to understand because public
organizations are living systems, since the main component is the human being as an
individual entity and as a member of a social group.
Adaptive and non-adaptive systems. Organizations are adaptive systems, since they react
or respond to changes in the context, producing a new situation of the system in response
to the reaction or response.
CHAPTER
FUNDAMENTALS OF SYSTEMS
DEVELOPMENT.
2.1 THE ANALYST AS A PROBLEM SOLVER
In essence, the system analyst applies a problem-solving approach to developing systems.
Problem solving is the act of studying the environment of a problem in order to implement
relevant corrective solutions. Problem is a term that includes:
1. Situations, actual or anticipated, that require corrective action.
2. Opportunities to improve a situation despite the absence of complaints about

it.
3. Instructions for changing a situation regardless of whether or not complaints

have been received about the current situation.
2.1.1 CHARACTERISTICS
Planning is the continued study of the environment of a problem in order to identify the
possible solutions it entails.
Ideally, the projects that are selected will provide benefits to the company in the long
term. Therefore, information system planning cannot be separated from the company
itself. It should be noted that many companies have not yet focused their attention on
which planning unit.
Analysis is the study of the problem environment and the subsequent definition and
establishment of priorities among the needs raised in order to solve the problem.
Design is the evaluation of the different alternatives as well as the detailed specifications
of the final solution.
Implementation is the construction or assembly of the solution to the problem that

culminates in a new environment based on said solutions.
Support is the ongoing maintenance and improvement of the solution over the course of
its life (which may last weeks, months, or years).
2.2 ELEMENTARY BLOCKS OF AN INFORMATION SYSTEM
System analysis develops the information system for organizations. Before studying the
system construction process, it is necessary to clearly understand the product you are
trying to create.
2.2.1 INFORMATION CONCEPT
An information system is an arrangement of integrated components whose objective is to

satisfy the information needs of an organization.
The purpose of an information system is to collect, process and exchange information

among the workers of a company. The information system has been designed to support
all the operations of the enterprise systems.
2.2.2 ELEMENTAL BLOCK PEOPLE
The first, and most important, block of information systems is the person. The
predominant philosophy in systems development should be to think
that systems are made for people.
System Owner
They sponsor and promote information systems. They

are normally responsible for setting the budget and
time frame necessary to develop and maintain the
information system, and ultimately decide the validity
of said information systems.
System users
They are those people who use the information system (and obtain direct benefits from it)
on a regular basis: Capture, validate, enter and store information data.
Users are the people for whom systems analysts develop information systems. System
users define:
1. The problems that have to be solved.

2. The opportunities that must be taken advantage of.
3. The needs to be satisfied
4. The business restrictions that will be imposed on information systems.
2.2.3 ELEMENTARY DATA BLOCK
Data can, and should, be interpreted as the raw material used to produce information.
Consequently, we consider that data should constitute one of the fundamental pillars of an
information system.
Most people use the terms data and information interchangeably. However, they do not
mean the same thing at all.
Data: is a collection of facts considered in isolation. The

data describes the organization. These isolated facts
provide meaning, but in general they are not useful on their
own.
Information: it is data that has been manipulated, with

which it is useful to someone. In other words, the
information must have value, otherwise it would be data.
Information tells people something they didn't know or
confirms something they have heard.
How system owners see data
Strictly speaking, the average system owner is not interested in the raw data, but in the
things that data describes. These things are company resources.
The company resources are:
1. Things essential to the purposes or objectives of the system.

2. Things that must be managed or controlled to achieve company goals and
objectives.
For system owners, data is itself a resource that helps better manage other business
resources. Which business resources are important to system owners for a given business
or information system, most of these resources fall into one of the following categories:
• Tangible things (for example, materials, supplies, machines, vehicles and

products).
• Roles (for example, customers, suppliers, employees, and account holders).
• Events (for example, orders, requests, contracts, trips, accidents or sales).
• Locations (for example, sales offices and warehouse facilities).
How users see the data
Users of an information system are typically data experts. They know the company's data
better than anyone. As information workers, they are responsible for capturing, storing,
processing, editing and using data on a daily basis. Unfortunately, they often view data
only in terms of how it currently applies or how they think it should be applied.
How system designers see data
System users define the data needs of an information system. System designers convert
these needs into databases and computer files that will support the elementary block of
activities of the information system. System designers view data in the form of
record arrangements, data structures, database schemas, file organizations, fields,

indexes and other technical items. Some of them, if presented appropriately, can be
correctly interpreted by system users. But in most cases that is not the case.
2.2.4 ELEMENTARY BLOCK ACTIVITIES
When engineers design a new product, that product must fulfill some function, do
something useful. The potential clients define the desired function and the engineer
creates a design that performs said function. ACTIVITIES define the function of an
information system.
A company's activities are daily processes that

serve to support its mission, goals and objectives.
Most businesses are organized around activities
such as marketing, sales, warehouse operations,
shipping and receiving, personnel management,
accounting, and production.
Information systems activities are the processes

that support business activities through:
1. The provision of data and the processing of information.
2. The improvement and simplification of business activities. Some activities can

be implemented in the form of software. Others have to be carried out by
people.
In essence, activities are jobs carried out for the company by both people and machines.
Some activities are repetitive. Others occur less frequently, sometimes almost never.
How system owners view activities
System owners are generally interested in the general plan of the company, in this case
the groups of activities called functions.
Functions are ongoing activities that support the operation of the company. In general,
they include very different activities that have something in common.
Business systems functions include sales, service, manufacturing, shipping, receiving,

accounting, etc.
Essentially, system owners view their business functions through various planning
parameters, such as goals and objectives.
Goals are general statements of intent, something the company wants to achieve.
Objectives are more specific purposes that help achieve goals.

How system users see activities
Users view activities based on different business processes.
Business processes are activities that have inputs and outputs. These processes are often
based on specific methods and step-by-step application procedures. Business processes
can be launched by people, machines or computers.
How system designers view activities
The vision that system designers have of the activities is conditioned by the limitations of
the specific technology. Sometimes the analyst may choose this technology. But often the
choice has already been made, and the analyst must use the available technology. In both
cases, the vision of the activities that system designers have is of a rather technical
nature.
2.3 LIFE CYCLE OF SYSTEMS DEVELOPMENT
The systems development life cycle (SVD) is the process by which systems analysts,
software engineers, programmers, and end users develop information systems and
computer applications.
In any case, it is a project management tool that plans, executes and controls systems
development projects.
2.3.1 ESSENTIAL PRINCIPLES FOR SYSTEMS DEVELOPMENT.
Involve the User: It is common to hear analysts and programmers talk about my system.
This attitude has given rise, to a certain extent, to a confrontational position between
analysts, programmers and users. Although programmers and analysts work hard to
create technologically magnificent solutions, these solutions often backfire on their
inventors because they do not address real organizational problems or even introduce
new technical or organizational problems. For this reason, the involvement of the user in
the project is an absolute necessity to achieve fruitful development of the systems.
Apply a problem-solving method: The systems development life cycle is, first and
foremost, a problem-solving method for manufacturing systems. The term problem is used
in this case as something that includes both real problems and opportunities for
improvement and standards imposed by management. The classic problem solving method
is as follows:
1. Identify the problem (or opportunity or norm).

2. Understand the context of the problem and its causes and effects.
3. Define the requirements to achieve an adequate solution.
4. Find alternative solutions.
5. Choose the best solution.
6. Design and implement the solution.

7. Observe and evaluate the impact of the solution. Refine the solution
accordingly.
Define phases and activities: Most CVDS consist of phases. In its simplest classical form,
CVDS consists of four phases:
1. System analysis
2. System design
3. System implementation
4. Systems planning
Establish Standards for Consistent Development and Documentation: To promote

proper communication across this constantly changing base of information systems users
and professionals, standards must be applied to ensure consistency of systems
development.
Systems development standards generally describe activities, responsibilities, guidelines,

or documentation and quality control requirements. These four types of standards should
be established in all phases of the life cycle.
Design systems that can grow and change: There is a vital flaw that information systems
professionals who need to develop systems often incur. Along with the ever-increasing
demand for systems development, many systems analysts have fallen into the trap of
developing systems that only meet the needs of today's users. Although at first glance it
may seem necessary, in practice it is almost always a failure.
Entropy is the term used by systems specialists to describe the natural and inevitable
deterioration of all systems.
CHAPTER
SYSTEM PLANNING
System planning aims to identify and prioritize those technologies and applications that
will produce maximum benefit for the company. Some of its synonyms are strategic
systems planning and information resource management.
Systems planning is achieved through the cooperation of the system owners, hence in the
pyramid model, it has to do with PEOPLE, DATA and ACTIVITIES.
3.1 PHASES OF PLANNING
3.1.1 PHASE 1: PLANNING STUDY
The first phase of studying systems planning consists of studying the mission of the
company. It is surprising that many companies have not formally documented their
mission, but in any case they all have a mission. The correct planning of information
systems depends on the quality of the company's planning. Accordingly, information

systems management often plays a key role in guiding and directing this phase.
Elementary Blocks for the Study Phase
The fundamental objectives of the study phase are:
• Establish the mandates of strategic systems planning. (This may involve

convincing senior managers of the company of the importance of strategic
systems planning)
• Establish working cooperation between information systems directors and the
company's highest-level managers.
• Analyze the company's strategies that could influence information systems.
3.1.2 PHASE 2: DEFINE AN INFORMATION ARCHITECTURE.
An information architecture is a plan for selecting the information technology and

developing the information systems necessary to support the enterprise's business.
The architecture phase may require six months or more to complete.
3.1.3 PHASE 3: ANALYSIS OF COMPANY AREAS
The purpose of the AAE is to devise a plan that leads to highly integrated information
systems applications for a business area. The analysis phase activates projects in order
to:
1. Develop a single and integrated database for the entire company area.
2. Develop a common network infrastructure for the business area (including
connections to other networks and the outside world).
3. Develop planned information systems application development projects that
will evolve around shared databases and network infrastructures, through
which they will achieve a high degree of integration.
Elemental Blocks
The fundamental objectives of an AAE are:
• Identify the company's needs for a shared database for the business area.
• Identify the needs in the company for a shared network for the business area.
• Refine the technical needs for the business area database and networks.
• Identify high-level needs in the company regarding the availability of
integrated applications in the business area.
3.2 REENGINEERING OF COMPANY PROCESSES

It is the set of study and redesign activities of the fundamental business processes,
independent of the organizational units or the support of the information systems, whose
purpose is to determine if the basic business processes can be simplified and improved
significantly.
CHAPTER
SYSTEM ANALYSIS
Systems analysis is the current study of business and information, the definition of the
needs and priorities expressed by users for the construction of a new information system.
4.1 ELEMENTARY BLOCKS AND PHASES

1. Project feasibility study (or inspection phase).
2. Study and analysis of the current system (or study phase).
3. Definition and establishment of priorities between user needs (or definition
phase).
4.2 DATA MODELING
A model is a representation of reality. Since a picture is worth a thousand words, models

are mostly graphic representations of reality.
Models can be established for existing systems, in order to obtain a better understanding
of these systems, for proposed systems as a means of defining needs and designs.
Implementation models show not only what a system is or does, but also what its physical
implementation is like. Its synonyms include technological model and physical model.
Deployment models are useful for documenting the data of an existing system. However,
analysts have learned that the data needs of proposed systems should be specified, at best,
by essential models.
Essential models are implementation-independent models that describe the essence of the
system (what the system does or should do), regardless of how the system is physically
implemented. Essential models are sometimes called logical models or conceptual
models.
Data modeling is a technique for organizing and documenting system data. Data
modeling is sometimes called database modeling, because data models are typically
implemented as a database.
4.2.1 DATA MODELING TOOLS.
There are numerous tools for data modeling. Both systems analysts and users will find
different tools on their way, sometimes even in the same organization. Therefore, it is
important that you become familiar with two other commonly used data modeling tools:
the Martin and Bachman data models. These two tools aim to represent and convey the
same information in the form of an entity-relationship diagram; However, each of them
has a different symbolic notation. Another tool is CASE, which are programs (software)
that automate or support one or more phases of the systems development life cycle. The
purpose of this technology is to accelerate the systems development process and improve
the quality of the resulting systems.
Entity-relationship diagrams
An entity-relationship diagram (ERD) is a data modeling tool that describes the

associations that exist between different categories of data within a business or
information system (not only does it tell how to implement, create, modify, use or delete
data.
4.2.2 HOW TO BUILD DATA MODELS.
There are many ways and methods to carry out data modeling. In this section we will see
when to do data modeling during systems development.
Data modeling throughout the life cycle
Data modeling can be performed during various phases of the systems development life
cycle. Data models are progressive, since enterprises and applications do not have final
models. Instead, a data model should be viewed as a living document that will change in
response to changes in the business. It is best to store data models in a dictionary, so that
they can be retrieved, expanded and edited over time.
Data modeling during systems planning
During the definition phase of systems planning, an enterprise data model is typically built.
This model reflects a high-level view of critical information entities. The enterprise data
model is also called the substantive data model, since its entities represent high-level
substantive issues about which the company's management requires information.
4.3 PROCESS MODELING
Process modeling is a technique for organizing and documenting a system's processes,

their inputs, outputs, and storage forms. Process modeling is a software engineering
technique, therefore, the reader may find similar models in software engineering courses.
On the other hand, the usefulness of process models goes far beyond the mere description
of software processes.
Essential process modeling addresses business processes from the points of view of system
owners and users. Accordingly, these models do not contain technological or
implementation details.
4.3.1 DATA FLOW DIAGRAM
A data flow diagram (DFD) is a process modeling tool that represents the flow of data
through a system and the jobs or processes carried out by said system.
Potential h Subscription
member ner coren
Order form to be
filled out
Subscription
system
MEM Member dBASE

file
Member and
musical
preference
Automatic order fulfillment date for Details
promotion Of the order
Orders by
to register date Rg Archio
of orders
Monthly or special
promotion
A4
marketing
department
Data Flow Diagram Conventions and Guidelines The main symbol of a flow diagram is
the process.
NAME IT REPRESENTS SYMBOL

Data flow Data in motion system

----------------•
Process System data
transformations.
Yo ...... ...
Data warehouse System data at rest
External or internal Origin and destination of

agent data flows entering and
leaving the system
A process is a set of tasks or actions performed from an input data stream to produce an
output data stream. Although the processes can be carried out by people, departments,
robots, machines or computers, for the moment we will only focus on the task or action
carried out, and not on who is in charge of said task or activity.
Data flow represents entering data into a process or obtaining data from a process.
Internal and external agents define the limits of a system. They provide net inputs or
outputs to a system. One of its most common synonyms is internal and external entity (not
to be confused with data entity). Agents are also sometimes called sources (of net inputs to
the system) or destinations (of net outputs from a system).
A data warehouse is an inventory of data. Its synonyms include file and database (although
these two terms have a nuance more related to the implementation of essential process
models).
Ideally, essential data stores should describe things about which the company wants to
store data.
This includes:
• Participants (e.g.
customers, suppliers,
employees, students,
instructors, etc.)
• Objects (as
products, parts,
textbooks, equipment,
etc.)
• Locations (e.g.
warehouses, sales
regions, buildings,
rooms, etc.)
• Events (such as orders,
time cards, requests,
courses, registrations,
etc.)
4.3.2 WHEN TO BUILD

PROCESS MODELS
Process modeling can be carried out in various phases of the systems development life
cycle. The process models are gradual, that is, in companies and applications they do not
have final models. Instead, a model should be considered a living document that will evolve
in response to changes experienced by the company. It is best to store process models in a
dictionary, so that they can be retrieved, expanded and edited over time.
Process modeling during systems planning
During the study phases of systems planning, generally no process modeling is done, the
focus of this stage is completely focused on the study of the company and the mission that
said company must fulfill.
During the definition phase of systems planning, a business process model is typically
built. This model contains an overview of business functions.
Data diagram or process model of the business area.
The degree of detail of said model varies depending on the specific methodologies used,
however, these DFDs do not, in general, have a sufficient level of detail to give way to the
design of specific computer applications. Rather, they are used to identify specific software
applications and prioritize them for later analysis and design phases.
Process modeling during system analysis

Process modeling usually builds an important part of many techniques and methodologies
of the study phase. Thus, analysts will create data flow diagrams for the implementation of
current systems to increase their knowledge about the systems and the problems associated
with them. Some analysts could convert these implementation DFDs into essential DFDs to
eliminate the inevitable bias that occurs when starting from existing implementation models
to consider alternative solutions.
The step towards system design
The essential process model obtained in systems analysis describes business process needs,
not technical solutions. When you move to systems design, the process model will become
more technical. It should become an application implementation model that will direct the
technical implementation of programs. Thus DFDs can also be used in the implementation
design phases.
4.3.3 STEP BY STEP PROCESS MODELING METHOD
We will use a phased approach to deliver a complete set of DFDs that can be used in the
future.
Step 1: Create a context data flow diagram
A context data flow diagram defines the scope and boundaries of the system and the
project. The scope of any project is always subject to change, therefore, so should the
context data flow diagram. Synonyms include context diagrams, context model, and
environmental model.
Context diagrams are difficult to prepare, since they must define the scope of action of the
project or system. To determine them, we propose the following strategy:
1. Think of the system as a container, to differentiate its interior from the exterior.
2. Ignore the purely internal tasks of the vessel. In this way, the classic black box
concept of systems theory will be applied.
3. Ask your end users what events or transactions the system should respond to.
Business events simply occur, bringing new data to the system.
4. For each event, ask your end users what responses the system should produce.
5. Ask your end users what fixed format reports the system should produce.
6. Identify the net data sources for each event. These sources will become internal
or external agents in the DFD.
7. Identify the net recipients of each response or output that the system should
generate. These destinations will also be internal and external agents.
8. Identify all possible external data stores. Many systems require access to files or
databases from other systems. Maybe they will use the data from these files or
databases.
9. Draw a context diagram for all the above information.
Step 2: Create a decomposition diagram that outlines the data flow diagrams.
There are two basic ways to create data flow diagrams for an entire system or application:
• Draw two data flow diagrams, each on a separate sheet of paper. The first
diagram, called general or level zero DFD, serves as a general level diagram, it
commonly consists of system or level one DFD, it is an extension of the first
diagram that provides a more detailed view of the system. It can contain from
ten to thirty processes.
• Create a set of tiered data flow diagrams. This method applies an explosion
technique, instead of the previous expansion method. The context data flow
diagram process is divided into its own data flow diagram that illustrates the
basic subsystems shown as subprocesses. Each of these subprocesses can, in
turn, be broken down into a data flow diagram that shows more detailed
processes.
A decomposition diagram, also called a hierarchy chart, shows the structure, or top-down
functional decomposition, of a system. It also provides us with an outline to prepare our
DFDs.
Step 3: Identify data stores
Before moving on to drawing our data flow diagrams, it may be useful to identify the
possible data stores that will be used in these diagrams. First, we create a composite data
store that represents all the data in the system. This data store is broken down into our data
model. Next, we will identify the primary data stores, one for each entity or associative
entity in the data model.
Step 4: Create a general data flow diagram
Using our decomposition diagram as an outline, we can now proceed to break down the
processes in the context diagram into a more detailed image of the system. This second
DFD is usually called a general data flow diagram. It shows its main subsystems and
functions, as well as the way in which they interact with each other. It is a useful way to
communicate the meaning and performance of the system in general terms.
General data flow diagram

A general data flow diagram shows the interaction between subsystems and/or key
functions.
Step 5: Create mid-level data flow diagrams
After having prepared the systems diagram, we can divide each of the processes of said
DFD to highlight a greater level of detail about the subsystems. Any process of a DFD is
susceptible to breakdown to reveal more detailed data flow diagram of said process. The
breakdown continues until a sufficient level of detail has been obtained. All but the most
detailed DFDs are often called mid-level DFDs.
Step 6: Create primary level data flow diagrams
Let's then complete the set of DFDs by levels by creating diagrams that show the detailed
process needs within the system. These diagrams are called primary or low-level data flow
diagrams. Periodically, decomposition diagrams should be reviewed to ensure that the
original scheme is correctly followed. This diagram contains an example of each of the
existing types of primitive processes:
• A simple inbound transaction process.
• An outbound transaction process

• A report production process.
• A data maintenance process.
Note that the original DFDs must show all appropriate data stores and original data flows.
4.4 NETWORK MODELING.

Network modeling is a diagram-based technique used to describe the shape of a business
or information system based on the location of its users, its data, and its processes.
4.4.1 CENTRALIZED CALCULATION AND TIME SHARING
Much of today's existing foundation of information systems and applications applies, with
reasonable success but at increasing cost, an outdated technology: centralized computing
and time sharing.
Centralized computing is a type of application architecture that uses a single processor,

typically located in a centralized data center or department. The computer is usually a
large system or a mini computer that allows simultaneous access to many users. It is also
called a centralized process.
Time sharing is a method by which users share a central computer. In a time-sharing

system, user interface processes (displays), input and output, data storage and retrieval
processes, and processing of logical enterprise systems are performed by a single central
processor.
4.4.2 CLIENT/SERVER SYSTEMS

Calculation with client/server systems is an extension of the cooperative process whose

realization has been possible thanks to the evolution of PCs, LAN and WAN networks, host
connectivity, graphical user interfaces and database management systems. distributor data.
In client/server systems, the process of an application is distributed among multiple

computers on a LAN or WAN network. Server computers provide common or imparted data
to said application or system.
There are several reasons that justify the current concerns in the process with clients /
servers:
• Client computers are becoming more powerful and cheaper than large
computers and mini computers.
• Server computers are increasing in power to a sufficient degree to handle the

workload of many client computers, again at a lower cost than large computers
and mini computers.
• Data storage can be brought closer than ever to the end user, where these
resources have the most value to the business.
• According to experts, thanks to graphical user interfaces, applications become

easier to learn and use.
• According to him, client/server applications are easier and less expensive to

build and maintain.
4.4.3 IMPLICATIONS FOR SYSTEM ANALYSIS
The choices facing today's systems analysts are confusing.

Nowadays, these analysts must know how to answer new questions:
• In what positions can a given application or information system be

implemented?
• How many users are there in each position?
• How could data and processes be distributed across different positions?
• How could data and processes be distributed in a given position?
These and other questions force the analyst to perfectly understand the geographic
distribution associated with each system.
4.4.4 POSITION CONNECTION DIAGRAMS
A job connection diagram (PCD) is a network modeling tool that describes the shape of a
system based on the location of its users, processes and data, as well as the necessary
interconnections between those locations.
Job Connection Diagram Conventions and Guidelines

Shows the set of symbols used for the documentation of business networks (geographical
scheme of a specific information system or application).
A position is any place in which there is a user who uses or interacts with the information
system or application.
Some examples of them could be:
Essentials Implementation Position

• City • Computer or Server Location
• University Fields • Place of Ending
• Building • Instead of racism of
• Dispatch
•
Terminals
Local Area Network Racism
• Dispatch Groups
•
• Branch
•
• Customer
• Supplier •
Wide Area Network Connection
• Place of a Peripheral
• Location of a communication
peripheral.
Essential post
Essential Locations are places where data and processes can eventually be distributed.
Initially, we may not be sure of the decisions to be made about the distribution of data and
processes in a DCP.
Essential connections
Essential Connections do not have a name in DCP. However, if it is useful, the connections
can be given a name that indicates the distance between the stations they connect. In cases
of mobile stations, distance intervals could be indicated, which would also be appropriate
in the case of geographically dispersed stations (e.g. customers).

CHAPTER
SYSTEM DESIGN
5.1 SYSTEM DESIGN CONCEPT
System design is the evaluation of the different alternative solutions and the specification
of a detailed computer solution. Also known as physical design.
5.1.1 SYSTEM DESIGN SELECTION PHASES
During the selection phase it is interactive to identify and analyze the various possible
options, and only then propose the most viable solutions based on the analysis carried out
.
ELEMENTARY BLOCKS IN THE SELECTION PHASES
In the Selection Phases, there are two fundamental objectives:
1. Identify and investigate alternative solutions, both manual and computer-based, that
can support obtaining the Object Information system.
2. Evaluate the feasibility of alternative solutions and recommend the best of these
solutions from a global point of view.
5.1.2 SYSTEM INTEGRATION DESIGN
Given the design needs and the integration needs of the object system, this phase involves
the development of the technical design specifications.
Elementary blocks for carrying out the design and integration phase
The design and integration phase has a double objective. First, and as a top priority, the
analyst seeks to design a system that satisfies the needs and is attractive to end users.
Ergonomics will play a central role during the design. Secondly, it is also very important,
the analyst aims to present clear and complete explanations to programmers and
information technicians. Our elementary blocks of information systems serve as a
framework to carry out the design phase:
• Networking: During the systems analysis phase, we established the system networking
requirements of the target system.
• Data: During the definition phase, we specify the content of each of the information
and data flows.
• Activities: The sequence of steps and control flow through the new system must be
specified during design.
• People: the roles played by the people participating in the new system must be
specified.
• Technology: Even if hardware is not selected or designed during the physical design
phase, the hardware imposes limitations on the system.
5.2 ANALYSIS OF DATA
5.2.1 DATA ANALYSIS FOR DESIGN DECISIONS
Data analysis: it is a procedure that prepares a data model for implementation in

the form of a non-redundant, flexible and adaptable database.
Normalization: is a data analysis method that organizes data attributes so that

they group together to form stable, flexible and adaptable entities.
Normalization: is a procedure with three stages that puts the data model in:
• First Normal Form

• Second Normal Form
• Third Normal Form
5.2.2 HOW AND WHEN TO PERFORM DATA ANALYSIS
In most organizations data analysis is carried out by the system analyst and/or database
administrator. He is also involved in the end user, but mainly as a reviewer of the final
data model.
5.2.3 METHODS FOR DATA ANALYSIS
There are numerous possible approaches to carry out data analysis. In which are:
Step 1: Verify or add keys to entities
Data analysis is carried out by systems analysts or database administrators who

frequently use the term key instead of identifier when communicating with their
information systems colleagues.
Systems analysts and database administrators use some special terms to differentiate
between the different specific types of keys that exist.
Primary Key: designates the attribute or attributes that uniquely identify one and only
one presence of each entity.
Candidate Key: is an alternative primary key used to uniquely identify one and only one
presence of an entity.
Concatenated Key: is a primary key composed of more than one data attribute. One of its
most common synonyms is combination keys.
Step 2: Put the entities in 1NF.

Step 5: Further simplification through inspection.
Step 6: Redraw the refined DER.
Step 7: Review and refine the data model.
5.3 PROCESS ANALYSIS AND DESIGN
5.3.1 CENTRALIZED, DISTRIBUTED AND COOPERATIVE PROCESSES
In applications with centralized processing , a main computer (typically a large system)

manages all activities, including inputs, outputs, data storage and retrieval, and logic
principles.
In applications with distributed processes , several computers (large systems,

minicomputers, and sometimes personal computers) perform all the activities. Each
computer on the network handles its own inputs, outputs, forms of data storage and
retrieval, and logical principles.
In applications with cooperative processing , multiple computers share their activities.

These computers cooperate with each other in a way that is transparent to users; each
user has the impression that all work is done on a single computer (possibly their own
PC).
5.3.2 CENTRALIZED AND DISTRIBUTED DATA STORAGE
The distribution of processes is not the only design problem. So is the location of data
warehouses. At the time, it was considered essential to be able to control data in a single
process center. Until very recently, the only known practical way to achieve this goal was
to store all data on one or several mainframe computers with complete control by the
data management group. Only some local data could be distributed to mid-range
computers, while the rest remained under the control of a data management group.
5.3.3 ENTRIES AND EXITS

Fundamental design decisions must also be made regarding inputs and outputs. The
decisions applied are usually simple (for example, how to work in Batch mode or Online
mode). Currently, we must also consider more modern alternatives, such as remote Batch,
in data entry without a keyboard, data entry using pencils, graphical user interfaces,
electronic data exchange, the exchange of images and documents, etc .
5.4 ANALYSIS AND GENERAL DESIGN FOR PROCESSES
5.4.1 IMPLEMENTATION DATA FLOWCHART
A deployment data flow represents the deployment of an input or output to a deployment

process. It also indicates accessing or updating a file or databases. It can also represent
the importance of data or the export of data between systems across an area. Finally, it
can represent the internal transfer of data between two processes implemented in the
same program.
5.4.2 SYSTEMS ORGANIZATION CHART
Systems flow charts are diagrams that show the flow of control through a system by
specifying all programs, inputs, outputs, and data access and retrievals in files/databases.
5.5 DESIGN OF FILES AND DATABASES
5.5.1 FILE AND DATABASE DESIGN CONCEPTS
Conventional files and modern databases are the heart of many information systems. The
design of computer files and databases can be more difficult because the storage and
organization of data on computer media requires the analyst to take into account complex
and sometimes contradictory issues such as, for example, the storage capacity and
performance.
5.5.2 DESIGN AND DOCUMENT FILES AND DATABASES
In this section, we will see how to design and document files. Remember that some
physical design decisions had already been saved in the project dictionary. We will then
proceed to design a file to illustrate this important system design task.
5.5.3 FILE DESIGN TECHNIQUES
There are two important and related issues that have a notable influence on file design:
• Minimize file redundancies
• Internal controls
5.5.4 FILE DESIGN
1. This file should be deployed as a variable length VSAM record.

2. The record size is specified as a minimum and maximum number of bytes.
3. There is usually a limit to the size of a block (for example, half the track on the disk).
4. Calculating the file size is very important, since it is not possible to store data for
which you do not have room.
5. It is also useful to express the size of the file in the form of tracks and cylinders,
because these tracks and cylinders may have to be reserved for the file.
6. To determine the number of cylinders required to store the file, you must know other
characteristics of the disc packages used by SoundStage Entertainment.
5.5.5 DESIGN AND DOCUMENT DATABASES
The design of any database generally involves the database administrator and database
specialists. These will manage the technical details and issues related to other
applications. However, it will be useful for the systems analyst to understand the
fundamentals of design principles for relational databases.
Step 1: Review database requirements

Step 2: Design the logical database schema
Step 3: Prototype the databases
A schema is the structural model of a database. Any given DBMS supports two schemas, a
logical schema and a physical schema.
These two schemas specify the physical and logical structures of the records in a
database.
The physical schema defines data structures, access methods, file organizations, indexes,
locking, pointers, and other physical attributes.
The logical schema defines the database in simpler terms from the point of view of end
users and programmers.
5.6 DESIGN OF ENTRIES AND EXITS
5.6.1 INLET AND EXIT DESIGN GUIDELINES
The outputs present information to users. Outputs, the most visible component of a work
information system, are the justification for the system.
During systems analysis, output needs and requirements were defined, but outputs were
not designed. There are two basic types of computer outputs. The first type is that of
external outputs.
External outputs emerge from the system to trigger or request confirmation of actions
outside.
Cyclic outputs are those that are typically implemented as forms that eventually return to
the system as inputs.
Internal outputs remain within the system to support the work of users and system
administrators.
5.6.2 CAPTURE OF DATA ENTRIES
Data capture is the identification of new data to be entered.
A source document is a form used to record data that will ultimately be entered into a
computer. Source documents should be easy for system users to complete and facilitate
rapid data entry in a machine-understandable format.
Data entry is the process of translating source documents into a machine-understandable
format. This format can be a punched card, an optically marked sheet, a magnetic tape,
or a flexible floppy disk, to name just a few.
Data entry is the actual entry of data into the computer in a machine-understandable
format.
5.6.3 INPUTS AND OUTPUTS FORMAT

The analyst is normally responsible for recommending the method, support and format of
all inputs and outputs.
Batch input methods and supports
One possible method of processing entries is known as batch entries.
Batch input is the oldest and most traditional input method. In it, the original documents
are collected and periodically delivered to data entry operators, who type said data
through a data entry device that translates it into a machine-understandable format.
Online entry methods and supports
An increasingly popular alternative method of processing major entries is known as

online entries.
Online entry is the capture of data at the point in the business where it originates and its
direct entry into the computer, preferably as soon as possible. Today, most, if not all,
systems use or are beginning to use online data entry methods.
Supports and output formats
A good systems analyst will consider all possible options for implementing an output,
especially the output support and output format.
A medium is where output information is recorded, such as paper or an image display

device.
The format is the way in which information is presented on a medium, for example in
columns of numbers.
5.6.4 INTERNAL CONTROLS OF ENTRANCES AND EXITS
Input controls ensure that data entry into the computer is accurate and that the system is
protected from accidental and intentional errors and abuses, including fraud.
Output controls ensure the reliability and distribution of the outputs generated by the
computer. For inputs, the following internal control guidelines are offered:
1. The number of entries should be tracked.
2. Special attention must be paid to ensuring that the data is valid.
5.7 USER INTERFACE DESIGN
5.7.1 USER INTERFACES STRATEGIES
Can any specific strategy be employed to design a better user interface? Indeed, there are
several strategies of this type and choosing the best one depends on the functions to be
performed and the characteristics of the system user. Let's briefly examine these
strategies:
• Selection in menus
• Instruction set
• Question-answer dialogues
• Graphics
5.8 PROGRAM DESIGN
5.8.1 MODULAR PROGRAM DESIGN
We are going to focus our attention on the way in which programming specifications must
be presented to computer programmers for implementation. To this end, we will see
program design as the combination of two components:
• Modular design, or breaking down a program into manageable fragments.

• Package, or set of inputs, outputs, files, user interface and process
specifications of each module.
5.8.2 HOW TO DO MODULAR PROGRAM DESIGN
The programs have been identified from the design units. Given these programs, we want
to break them down into manageable models around which we can write program
specifications. Ali programs may build and test each module differently. The modules can
then be integrated according to the structure graph and tested as complete programs.
Step 1: Define the high-level structure

Step 2: Identify transaction centers
5.8.3 MODULAR DECOMPOSITION OF PROGRAMS
A module is a group of executable instructions with a single entry point and a single exit
point.
There are some modules that perform unique functions. Some of them would be:
• Read a record
• Edit a record
• Calculate a payment
• Add a record to a file
5.8.4 PACKAGE PROGRAM SPECIFICATIONS
The program specifications package is a collection of design documentation that clearly

communicates the requirements of each computer program in the system. All programs
perform three types of tasks: entering or reading data, manipulating input data, and
outputting data or information. In other words, all program tasks can be classified
according to input, process and output (EPS) requirements. In this model it will help us
obtain the requirements to implement a computer program.
CHAPTER
SYSTEMS IMPLEMENTATION
6.1 CONCEPT
It is the construction of the new system and the delivery of said system to production
(daily exploitation). Unfortunately, one of its common synonyms is systems development.
6.2 CONSTRUCTION PHASE TESTING NETWORKS AND

DATABASES IN IMPLEMENTATION
In many cases, new or improved applications are built around existing networks and
databases. If this were the case, this phase would be omitted. However, if the new
application requires new or modified networks and databases, they should normally be
implemented before writing or installing software, since the application programs will
make use of these networks and databases. Thus, the first phase of some implementations
will be the construction and testing of networks and databases.
Elementary blocks for building and testing networks and databases
The fundamental objectives of the network and database construction and testing phase
are the following:
• Build (or modify) and test networks.

• Build (or modify) and test empty databases.
Activities, participants and techniques of building and testing networks and

databases
Activity 1: Build and test networks (if necessary)

Activity 2: Build and test databases (if necessary)
6.3 INSTALLATION AND TESTING PHASE IN THE

IMPLEMENTATION OF SYSTEMS
It is during this phase that software packages are installed and tested. To ensure that the
integration requirements of the new system are met, a full system test is performed again.
Finally, during this phase a conversion plan is developed to successfully guide the
delivery of the new system to production.
Elementary blocks for the installation and testing phases of the new system
The fundamental objectives of this phase are:
• Install and test new software packages purchased from vendors.

• Perform a complete system test to ensure that custom software packages and
purchased software work together appropriately.
• Develop a detailed plan to convert the old system to the new system.
Activities, participants and techniques of the installation and testing of the

new system
Activity 1: Install new software package (if necessary).

Activity 2: Test the package (if necessary).
Activity 3: Perform a system test (if necessary).
Activity 4: Prepare a conversion plan.
6.4 DELIVERY PHASE OF THE NEW SYSTEM FOR

IMPLEMENTATION EXPLOITATION.
Now, let's move on to the last implementation phase of our life cycle: the delivery of the
new system for production. The analyst is the main figure in this delivery phase,
regardless of his or her participation in the construction of the system.
Elementary blocks in the delivery phase of the new system for its
exploitation
The purpose of the new system delivery phase for operation is to smoothly convert the old
system into the new system. To achieve this purpose of this phase, we must achieve the
following objectives:
• Install the files or databases that the new system will use.
• Offer training and documentation to people who will use the new system.
• Convert the old system to the new system.
• Evaluate the project and the final system.
Activities, participants and techniques of the delivery phase of the new

system for its implementation
Activity 1: Install the files or databases.

Activity 2: Provide training to system users.
Activity 3: Move to the new system.

CHAPTER
SYSTEM SUPPORT
7.1 SYSTEM MAINTENANCE
Regardless of how a system or application is designed, built and tested, errors will
inevitably appear. Some of these errors will have their origin in failures to communicate
needs. Others will be caused by design defects. There will also be those caused by
unforeseen and, therefore, unproven situations. And finally, errors can also be caused by
unforeseen misuse of programs. In all of these situations, corrective action must be taken.
We call these actions system maintenance or program maintenance.
Objectives and elementary blocks of systems maintenance
The fundamental objectives of systems maintenance are:

• Make predictable changes to existing programs to correct errors that were
made during system design and implementation. Consequently, we exclude
improvements and new needs from this activity.
• Preserve those aspects of the programs that have already been corrected. On
the contrary, we will try to avoid the possibility that the arrangements in said
programs give rise to other aspects of them and new needs.
Tasks, system maintenance participants
Let's now review the general guidelines for reading these diagrams:
• The silhouettes represent people or departments starting tasks.

• The rounded rectangles represent tasks. Each task is uniquely listed for
identification purposes. The task name is printed in the top half of the symbol.
The participants in this task are printed in the lower half of the symbol. The
participant is always the person who directs the task.
• Dates reflect the inputs and outputs of a task. They all have a name. When one
of these inputs or outputs is referenced in the text, underlines appear.
7.2 SYSTEM RECOVERY: OVERCOME GENERAL FAULTS.
From time to time, it is inevitable that a system will fail. This failure generally results in
what is called an aborted program (also called ABEND or crash) and possible loss of
data. So, it is often the systems analyst who is in charge of fixing the system or acting as
an intermediary between the users and those who must recover the system. The purpose of
this section is to briefly summarize the role of the analyst in systems recovery.
This activity does not require a multitasking flowchart to detail its steps, and can be
summarized as follows:
In many cases, the analyst can sit at the user terminal and recover the system. Sometimes,
it can be as simple as pressing a specific key or restarting the main computer.
7.3 END USER SUPPORT
Another ongoing and relatively routine activity in systems support is routine end-user
assistance. Regardless of the user training or the quality of the documentation, users will
require additional assistance. The systems analyst is generally available to users to offer
help in the daily use of specific applications. In critical applications, the analyst must be
available day and night.
Once again, it is necessary to provide a detailed flowchart for this activity. The most
characteristic tasks include:
• Routine observation of system use.

• Carrying out studies and meetings to determine the degree of user satisfaction.
• Change company procedures so that they are clearer (they will be written and
recorded in the dictionary).
• Offer additional training.
• Write down ideas and requests for possible improvements in the dictionary.
7.4 SYSTEMS IMPROVEMENTS AND REENGINEERING
The adaptation of an existing system to new needs is a possibility always open in all newly
implemented systems. The maintenance linked to these adaptations forces the analyst to
analyze the new needs and return to the appropriate phases of analysis, design and system
implementation. In this section, we will examine two types of adaptive maintenance:
systems improvements and systems reengineering.
Objectives and elementary blocks of system improvements and

reengineering
The goal of system enhancements is to modify or expand the application system in

response to constantly changing business needs. This objective can be related to the
elementary blocks of information systems as follows:
• People: For the most part, system improvements are proposed by system
users, although system analysts, designers, and builders can also detect
potential technical issues related to performance, security, and internal
controls.
• Data: Many system improvements are demands for new information that can
be derived from existing stored data. Some data enhancements may require
expanding data storage.
• Processes: Most system improvements require modification of existing

programs or creation of new programs to expand the overall scope of the
application system.
• Networks: For the most part, system improvements have nothing to do with
networks.
• Technology: For the most part, system improvements are based on

technology.
CHAPTER
PROJECT MANAGEMENT
In any systems development project, effective project management is necessary to ensure
that the project meets its objectives and is developed within an acceptable budget.
Project management is the process by which the development of an acceptable system is

planned, directed and controlled at minimum cost and within a specific period of time.
Although the tools and techniques of systems analysis and design play a fundamental role
in obtaining systems that work, these methods are not sufficient on their own. As we saw
in the previous mini-case, poor project management, or making them ineffective. The
mini-case that opens the module highlights the four most common consequences derived
from poor project management:
• Unmet or unidentified needs.

• Uncontrolled change of the project scope.
• Excess cost.
• Delivery delays.
These problems are not always due to poor project management, but there is no doubt
that it has an important responsibility for their appearance.
8.1 CAUSES OF FAILED PROJECTS BY MANAGEMENT.

Poor management of expectations. The problem is that during the early phases, the scope
of the project is rarely precise enough. And in many projects, this scope is never precisely
defined. If the project manager is unaware of this problem, the project team will often be
forced to increase the scope of the project (this problem is sometimes called growing
needs syndrome) or make last-minute changes. in specifications and programs.
One of the main problems associated with cost overruns is that many methodology or
project plans require an excessively precise estimate of costs before starting the project.
These estimates are made after a quick prior or feasibility study.
To be a good project manager, the analyst must have good training in basic management
functions.
Basic functions of the project manager
The project manager is not simply an experienced analyst who takes charge of a project.
A project manager must apply a different set of techniques and knowledge than an
analyst. These functions include planning, recruiting, organizing, scheduling, directing,
and controlling.
8.2 PROJECT MANAGEMENT TOOLS AND TECHNIQUES

There are many project management tools and techniques, enough to fill an entire book.
In this section, we will provide an introduction to two project planning and control tools,
and a simple expectations management tool.
8.2.1 PERT CHARTS
Pert , which means Project or Program Evaluation and Review Technique (project or
program evaluation and review technique), was developed at the end of the 1950-1959
scholarship to plan and control the army's large weapons development projects. US. It
was developed to demonstrate the interdependence of project tasks when project planning
is carried out. In essence, PERT is a technique of interrelated graphical models.
THE GRAPHIC
The PERT chart is the graphic representation of the relationships between all the events
and tasks necessary to carry out a project.
An event (represented by a circle) is a specific instant in time; Therefore an event does
not consume time. An event can be the beginning or the end of a task, a point in time that
can be clearly recognized and identified.
An activity (represented by a date) is the work necessary to achieve an event. An activity
cannot begin until all preceding activities have been completed.
Thus a graph is composed of a certain number of events linked together by activities.
The graph begins with a single initial event, branches into several paths that link various
events, and ends in a final event that signals the end of the project.
Since PERT is an event-oriented technique, the focus is on the beginning or end of
events rather than the activities themselves.
BASIC RULES
Rule 1: One and only one arrow is used to represent an activity to be executed. The length
of the arrow and the direction it is facing have no meaning.
Rule 2: The diagram is constructed by connecting arrows that represent activities,
considering for each one the following three questions:
a) What immediately precedes this activity
b) What immediately follows this activity
c) What activities are concurrent.
Rule 3: Start the diagram with a preliminary arrow.
Rule 4: List the events.
Rule 5: Use dummy activities only when you need to maintain the logic of the diagram.
TIME ESTIMATES
Once a correct graph has been achieved, with the appropriate details, it is necessary to
establish an estimate of the duration of each of the activities; and although a single
estimate could be used, three estimates are usually used:
1 .- Optimistic Duration (to): time needed to carry out the activity if no unforeseen
difficulties or complications arise.
In most cases the probability of carrying out the activity in this time is small. A rule of
thumb for this case is: There is only a one percent chance of performing the activity in a
time less than the optimistic duration.
2 .- Most likely duration (tm): time that the activity is most likely to need to be carried
out. This estimate should take into account normal circumstances, allowing for some
delays due to unforeseen events, and should be based on the best information available.
3 .- Pessimistic Duration (tp): time needed to carry out the activity if unusual difficulties
and unforeseen complications occur.
COLLECTION OF DURATION ESTIMATES

Duration estimates will be obtained by the PERT analyst from the people who are
responsible for carrying out the work represented by the activities.
Durations are usually requested in interviews, that is, orally, in preference to written
communications. The estimates will be obtained without following the sequential order
represented by the graph. If the estimates are obtained following a path, there is a
tendency to mentally add up and compare with the preconceived idea one has of the
duration of the path. When this occurs and the accumulated time is different from the
preconceived one, the estimator consciously or unconsciously tends to equate the two
estimates. Evaluating activities out of order helps each one to be considered
independently of the others.
NUMBERING OF EVENTS
The events should be numbered sequentially when the graph is finished, that is before
starting the calculations.
When numbering begins at the initial event and continues sequentially through the graph,
each successor event has a larger number than its predecessors.
In this way the circuit can be easily detected, since an activity will have a larger number
at the tail of the arc than at the head.
STEPS TO DIAGRAM A PROJECT

1 .- ACTIVITIES LIST
Formulate the list of activities to be developed as follows:
• TO Feasibility study.
• B General system design.
• cStaff selection.
• dStaff training.
• AND Application study.
• FFinancing study.
• gEquipment study.
• h Equipment selection.
• Yo Final evaluation.
• J. Programming.
• K Equipment shipment.
• l Equipment reception.
• M Preparation of the place.

• N Installation of the communications system.
• EITHER Equipment installation.
• P Program development.
• Q User training.
• R System test.
• S System setup.
• T Parallel operation.
2 .- LOGICAL SEQUENCE OF ACTIVITIES

Based on the previous list, the logical sequence of activities is established.
3 .- DRAW THE NETWORK DIAGRAM

When constructing the diagram, the following must be taken into account for each of the
activities:
What activity immediately precedes this activity
What activity immediately follows this activity
What activities are concurrent
4 .2.2 GANTT CHARTS
The Gantt chart is a simple time chart tool that was developed by Henry L. Gantt in 1917.
Gantt charts, which still remain popular today, are quite effective for planning and
evaluating project progress. Like PERT charts, Gantt charts are based on a graphical
approach. The popularity of Gantt charts stems from their simplicity: they are easy to
learn, read, prepare, and use.
A Gantt chart is a simple bar chart. Each bar symbolizes a project task. In a Gantt chart,
the horizontal axis represents time. Since Gantt charts are used to chain tasks together,
the horizontal axis should include dates. Vertically, and in the left column, a list of the
tasks is offered.
5 .2.3 PROJECT MANAGEMENT SOFTWARE
Project management software was introduced already in chapter 5 as a type of CASE

tool. Examples of packages of this type are Proyect, from Microsoft, and Proyect
Manager Workbench, from Applied Business Technology. These packages greatly simplify
the preparation of PERT and Gantt charts, allowing automatic transformation between
both types of charts. The software also allows project managers to assign human and
financial resources to tasks, report on project progress, and conduct if-then tests when
attempting to modify the project plan as a result of schedule deviations.
6 .2.4 HUMAN RESOURCES MANAGEMENT
Managing or supervising project team members is as important as planning and

controlling the project schedule, budget, and expectations. This question could deserve an
entire module dedicated specifically to it.
8.3 FACT INVESTIGATION TECHNIQUES
8.3.1 FACT INVESTIGATION CONCEPTS
Fact finding is a formal process that uses search procedures, interviews, questionnaires,
sampling, and other techniques to collect all available information about systems, their
needs, and displayed preferences.
8.3.2 FACTS THAT SHOULD BE COLLECTED BY THE SYSTEMS ANALYST

AND WHEN
Fact investigation is of vital importance primarily during the planning and systems
analysis phases. It is during these phases that the analyst learns the vocabulary of the
company and the system, such as its problems, opportunities, limitations, needs and
priorities. Fact research is also used during the design and support phases, but to a lesser
extent.
8.3.3 FACT INVESTIGATION METHODS AVAILABLE
Now that we have a framework for our fact-finding activities, we can introduce six
common fact-finding techniques:
1. Sampling of existing documentation, forms and files.

2. Research and visits to facilities.
3. Observation of the work environment.
4. Questionnaires.
5. Interviews.
6. Application Suite Design (DCA).
8.3.4 SAMPLING OF EXISTING DOCUMENTATION, FORMS AND FILES
In particular, when studying an existing system, a good understanding of it can be gained

by analyzing existing documentation, forms and files. A good analyst deduces facts from
existing documentation rather than from people.
Document and file sampling techniques
Since it would not be practical to study all the presences of each of the forms,
Analysts often apply sampling techniques to get a general idea of what is happening in the
system.
Sampling is a process of collecting existing documents, forms and files.
How to determine the sample size
The size of a sample depends on how representative you want the sample to be. There are
many design issues and factors, in themselves a good reason to attend an introductory
course on statistical techniques.
Select the sample
Two commonly used sampling techniques are random sampling and statification
sampling.
Random sampling is a sampling technique characterized by lacking a model or plan for

selecting sample data.
Stratification is a systematic sampling technique that attempts to reduce the inherent

variance of values by expanding sampling and eliminating excessively high or excessively
low values from the sample.
8.3.5 INVESTIGATION AND VISITS TO FACILITIES
A second fact-finding technique is to conduct a thorough investigation of the

application and the problem. Good sources of information are commercially
available computer publications, as well as interviews typically read by end users.
In this way, it will be possible to learn how others acted to solve similar problems.
This way you can also know whether or not there are software packages that can
solve our problem.
8.3.6 OBSERVATION OF THE WORK ENVIRONMENT
Observation is one of the most effective techniques for collecting data that helps us
understand a system.
Observation is a fact-finding technique during which analysts either actively participate

or act as spectators of the activities carried out by a person to better understand a system.
This technique is frequently used when there is uncertainty about the validity of data
collected by other means or when the complexity of certain aspects of the system prevents
clear explanations to end users.
8.3.7 QUESTIONNAIRES
Another fact-finding technique is that of carrying out studies using questionnaires.
Questionnaires are specific documents that allow the analyst to collect the information
and opinions expressed by the people surveyed.
Types of questionnaires
There are two questionnaire formats: free format and fixed format.
Free-form questionnaires allow the respondent great freedom of response. The

respondent writes the answer in a blank space reserved immediately below the question.
Fixed format questionnaires contain questions that require specific answers from
respondents.
Questionnaire design
Good questionnaires have to be designed. If questionnaires are written without having

first designed them, the chances of success will be limited. The procedure indicated below
has already proven its effectiveness:
1. Determine what facts and opinions should be collected and from what people. If the
number of people is very large, consider using a smaller, randomly selected group of
respondents.
2. Based on the necessary facts and opinions, determine which type of questionnaire
would produce better responses: fixed format or free format. Often, a combination of
formats is used to allow free-form clarifications to fixed-format responses.
3. Write down the questions. Examine them carefully to avoid that they contain errors of
expression or that could lead to erroneous interpretations. Make sure the questions
do not give away your personal opinions. Edit the questions.
4. Test the questions on a small sample group of respondents. If your respondents had
trouble answering them or if the answers were unhelpful, modify it.
5. Make copies and distribute the questionnaire.
8.3.8 INTERVIEWS
The personal interview is generally recognized as the most important and frequently used
fact-finding technique.
Interviews are fact-finding techniques during which the analyst collects information
provided by people face to face.
Type and techniques of interviews
There are two types of interviews, structured and unstructured.
In structured interviews , the interviewer has a specific set of questions that he or she
wants to ask the interviewee.
Unstructured interviews are conducted with only a general objective or topic in mind and
few, if any, specific questions. In this case, the interviewer counts on the interviewee to
define the general context of the interview and direct the conversation.
How to conduct an interview
The success of a systems analyst depends, at least in part, on his or her ability to
interview. A good interview will involve selecting the right people for the interviews,
intensive preparation for the interview, correct conduct of the interview and follow-up of
the interview.
Co-design of applications
The classic fact-finding technique has always been to conduct separate interviews with
end users. However, many analysts have had big problems with interviews: they, taken
separately, often yield conflicting facts, opinions, and priorities as conclusions. As a
result, numerous follow-up interviews and group meetings have to be done. For this
reason, many information centers are using group work sections as substitutes for
interviews.
Application Co-Design (ACD) is a process by which highly structured group meetings

are held that bring system users, system owners, and analysts together in the same room
for an extended period of time.
CHAPTER
ANALYSIS OF VARIABLES
9.1 VARIABLE ANALYSIS
It deals with the variable elements and calculation methods used by the analyst and
companies when getting involved in the development of an application.
9.1.1 PROGRESSIVE CONTROL METHOD
This module talks about cost-benefit analysis and other feasibility topics that are of
interest to analysts and users of information systems. There are few issues as important as
this. Feasibility analysis is not, in fact, a systems analysis, nor is it a systems design.
Rather, it is a cross-life cycle activity and should be carried out permanently in the course
of systems projects.
9.1.2 VIABILITY CONTROL POINTS IN THE LIFE CYCLE
Let's start by giving a formal definition of feasibility and feasibility analysis
Viability is the measure of the benefit obtained in an organization thanks to the

development of an information system.
Feasibility analysis is the process by which feasibility is measured.
Feasibility test table
So far, we have defined feasibility and feasibility analysis, and pointed out the feasibility
checkpoints in the life cycle. In their Mayorga, analysts agree that there are four
categories of viability tests:
• Operational feasibility is a measure of the correct functioning of a possible solution to

problems within an organization. It is also a measure of the feelings that a system or
project awakens in the people who participate in it.
• Technical feasibility is a measure of the success of the implementation of a specific

technical solution and the availability of the necessary resources and technical
knowledge.
• Date feasibility is a measure that indicates whether a project is reasonable in meeting

its schedule.
• Economic feasibility is a measure of the cost effectiveness associated with a project or

solution. It is often called cost-benefit analysis.
9.2 COST AND BENEFIT ANALYSIS TECHNIQUES
Economic feasibility has been defined as a cost-benefit analysis.
9.2.1 HOW MUCH WILL THE SYSTEM COST?
The costs can be classified into two categories. There are costs associated with the
development of the system and costs associated with the operation of the system.
The costs of developing an information system can be classified according to the phase in
which they occur. Systems development costs are generally incurred only once and do not
occur again after the project is completed. Many organizations have standard categories
of costs that they must evaluate. In the absence of such categories, the following list could
help us:
• Personnel cost
• computer use
• Training Costs of supplies, duplications and equipment.
• Cost of any new computer equipment or software.
Fixed costs occur at regular intervals and in relatively fixed ratios. Examples of fixed
operating costs are:
• Rental payments or software license payments.

• Prorated salaries of information systems operators and support staff (although
salaries tend to increase, the increase is gradual and does not usually change
dramatically from month to month).
Variable costs occur proportionally to certain utilization factors. For example:

• Computer usage costs (e.g. CPU time used, connection time used, storage used).
• Supplies (for example, pre-printed forms, used printer paper, punched cards,
floppy disks, magnetic tapes, and other consumables), which swept up the
workload.
9.2.2 WHAT BENEFITS WILL THE SYSTEM PROVIDE?
Benefits generally increase profits or reduce costs, both highly desirable features in any
new information system.
To the greatest extent possible, benefits should be quantified in current currency. Benefits
can be classified as tangible and intangible.
Tangible benefits are those that are easy to quantify.
Tangible benefits are usually measured in terms of monthly or annual savings, or

company profits.
Intangible benefits are those that are thought to be difficult or impossible to quantify.
Unless these benefits are, at a minimum, identified, it may be entirely possible that many
projects will not be viable.
9.2.3 IS THE PROPOSED SYSTEM EFFECTIVE IN TERMS OF COST?
There are three well-known techniques for evaluating economic viability, also called cost
effectiveness.
1. Amortization analysis.
2. Return on investment.
3. Net present value.
CHAPTER
INTERPERSONAL TECHNIQUES
10.1 COMMUNICATE WITH PEOPLE
Communication barriers frequently arise in information system projects, usually created
intentionally or accidentally by project participants. System owners and users use their
own language to describe forms, methods, procedures, etc. Designers and system builders
have their own terms, acronyms and clichés to describe the same things. As a result, a gap
has opened up in communication between these two groups.
10.1.1 FOUR GROUPS FOR INTERPERSONAL COMMUNICATION DURING

SYSTEMS PROJECTS
For years, language and communications experts have told us that the secret to
maintaining good and effective oral and written communication skills consists of knowing
who we are addressing. At least four different groups can be identified:
1. Systems designers, including our colleagues (other information systems analysts and
specialists).
2. System builders, programmers and technical specialists who will develop the system in
practice.
3. System users, those people whose daily work will be directly or indirectly affected by
the new system.
4. Systems owners, who, in addition to being users of the systems, sponsor the project
and approve the expenses of the systems.
10.1.2 USE OF WORDS: POSITIVE AND NEGATIVE EXPRESSIONS
Positive expressions are words or phrases that provoke positive responses in listeners.
These terms can be used very effectively to convince those listening to us of the
advantages of the changes being proposed. Managers will more easily accept those ideas
that promote actions reflected by positive expressions.
Negative expressions are words or phrases that provoke negative responses in listeners.
These terms can also be used effectively to convince these listeners of the advantages of
the proposed changes. Managers will more easily accept those ideas that eliminate the
facts reflected by negative expressions.
10.2 EMAIL
It seems that new and more effective means of communication between people have
continually been found. One of the most recent forms of interpersonal communication, of
particular importance to the systems analyst, is email.
Email gives us the opportunity to create, edit, send and receive information electronically,
usually through the use of some type of computer network. The only thing you need is a
computer and some type of email software. The advantages of this form of communication
are obvious. A person can send and receive messages almost instantly in contact with
virtually any place in the world (as long as the sender and receiver are connected to some
kind of computer network). These messages can be read, stored, printed, edited or
deleted. Furthermore, once the mail system software and computer network have been
installed, the actual cost of sending messages is very small.
10.3 BODY LANGUAGE AND PROXEMICS

Body language is all the information that one person communicates to another without
using words. Body language is a form of non-verbal communication that we all use, often
without realizing it.
Proxemics is the relationship established between people and the space that surrounds
them. Proxemics is an important factor of communication that can be controlled by
analysts who know and master it.
10.4 MEETINGS
During the course of a systems development project, many meetings are typically held.
A meeting is an attempt to achieve an objective as a result of its discussion by several

people.
10.4.1 PREPARE A MEETING
Many people have a negative image of meetings because many meetings they have
attended were poorly organized and poorly run. Meetings are also very expensive,
because they require several people to spend time that could have been better spent on
more productive work. The more people participating in a meeting, the more expensive it
is.
10.4.2 LEAD A MEETING
Try to arrive on time, but don't start the meeting until everyone is present. If any
important participants arrive more than fifteen minutes late, consider canceling the
meeting. Once this has started, try to avoid interruptions or delays caused by, for
example, telephone calls. Have enough printouts for all participants. Get off to a good
start by reviewing the agenda so that the discussion points become ownership of the entire
group. Then address each agenda item according to the time allotted when the meeting
was scheduled. The group leader must ensure that no person or subgroup becomes
dominant in the meeting or is marginalized. Decisions should be made by consensus or
majority vote. A basic rule is to always stay on schedule: stay on schedule and finish on
time. If all agenda items are not discussed, another meeting will be scheduled.
10.4.3 FOLLOW A MEETING
As soon as possible after the meeting has concluded, the minutes of the meeting should be
sent. These minutes should be expressed in a short written summary of what occurred
during the meeting: points discussed, decisions made, and points for future
considerations. The minutes are normally prepared by the secretary, a member of the
team appointed by the group leader.
10.4.4 PROJECT MEETINGS
A special kind of meeting held by the analyst is called a project meeting.
The project meeting is a special type of meeting called to conduct group reviews of
systems development documentation. These meetings can be used to review almost any
type of detailed documentation.
10.4.5 WHO SHOULD PARTICIPATE IN THE PROJECT MEETING?
A project meeting group should consist of at most seven participants. All members of the
meeting should be treated as equals. The analyst in charge of preparing the
documentation to be reviewed should present this documentation to the group during the
meeting. Another analyst or key system user should be appointed as the meeting
coordinator. The coordinator is responsible for scheduling the meeting and ensuring that
all participants obtain documentation well in advance of the meeting date. The remaining
participants include system users, analysts or specialists who will involve documentation.
These reviewers may also take on special roles. For example, some may evaluate the
accuracy of documentation, and others may comment on quality, standards, and technical
issues.
10.4.6 LEAD A PROJECT MEETING
All participants must agree to follow the same set of rules and procedures. Additionally,
participants must agree to review the documentation; This task should not be performed
by the person who prepared the documentation. The basic purpose of the meeting is error
stopping, not error correction. Analysts should never refute reviewers' comments. A
defensive attitude inhibits constructive criticism. The coordinator is responsible for
ensuring that these rules are explained, understood and obeyed in the appropriate way.
Reviewers should be encouraged to offer at least one positive and one negative comment
in order to ensure that the meeting is not superficial.
10.5 WRITTEN REPORTS
The business and technical report is the primary method used by analysts to
communicate information about a systems development project. The purpose of the report
is to inform or convince, or perhaps both.
10.5.1 LENGTH OF A WRITTEN REPORT
The written report is a method that is frequently abused by analysts to communicate with
system users. We have a tendency to generate long, voluminous reports that look
impressive. Sometimes such reports are necessary, but other times they are not. If a 300-
page technical report is placed on a manager's desk, the manager can be expected to skim
it, but not read it, much less study it carefully.
The size of the report is an interesting question. After many unsuccessful experiences, we
have learned to apply the following general guidelines to limit the size of reports:
• For high-ranking managers: one or two pages.

• For mid-level managers: three to five pages.
• For supervisory managers: less than ten pages.
• For administrative staff: less than fifty pages.
10.5.2 WRITING OF THE BUSINESS OR TECHNICAL REPORT
The way you write can have a great influence on your career path in any occupation.
Below we offer some guidelines in this regard:
• Paragraphs should convey a single idea. They should easily flow from one to
another. Poor paragraph writing almost always leads to deficiencies in the
exposition.
• The sentences should not be too complex. The average length of a sentence should
not exceed twenty words. Studies suggest that sentences longer than twenty words
are difficult to read and understand.
• It will be written in active voice. The passive voice becomes heavy and boring
when used systematically.
10.5.3 ORGANIZATION OF THE WRITTEN REPORT
There is a general pattern for organizing any report. All reports consist of parent and
child elements.
Primary elements show actual information that a report is trying to convey. Examples of
these elements are the introduction and the conclusion.
While parent elements present the actual information, all reports also contain child
elements.
Secondary elements summarize the report so that the reader can easily identify both the
report and its parent elements. Secondary elements also add a professional finish to
reports.

Systems Analysis and Design Manual

Uploaded by

Copyright:

Available Formats

Systems Analysis and Design Manual

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systems Analysis and Design Manual

Uploaded by

Copyright:

Available Formats

Analysis and design of systems 1

CONCEPTS OF SYSTEMS ANALYSIS.

1.2 SYSTEMS NEED

1.3 GENERAL CONCEPTS OF THE ANALYSIS

It is also a set or arrangement of elements to achieve a predefined objective in the

• The information domain of a problem must be presented and understood.

• Define the functions that the Software must perform.

• Represent the behavior of the software as a result of external events.

• Hierarchically divide the models that represent information, functions and

• Hardware , electronic and electromechanical devices, that provide fast, accurate

• Personal , are the operators or direct users of the System tools.

• Database , a large collection of information organized and linked to the System

• Documentation, Manuals, forms , and other descriptive information that details

• Identify the Client's needs.

• Perform a Technical and economic Analysis.

• Assign functions to Hardware, Software, personnel, database, and other elements

• Establish budget and time planning constraints.

1.4 SYSTEMS CLASSIFICATION

1. Situations, actual or anticipated, that require corrective action.

2. Opportunities to improve a situation despite the absence of complaints about

3. Instructions for changing a situation regardless of whether or not complaints

Implementation is the construction or assembly of the solution to the problem that

culminates in a new environment based on said solutions.

2.2 ELEMENTARY BLOCKS OF AN INFORMATION SYSTEM

2.2.1 INFORMATION CONCEPT

An information system is an arrangement of integrated components whose objective is to

The purpose of an information system is to collect, process and exchange information

2.2.2 ELEMENTAL BLOCK PEOPLE

They sponsor and promote information systems. They

1. The problems that have to be solved.

2.2.3 ELEMENTARY DATA BLOCK

Data: is a collection of facts considered in isolation. The

Information: it is data that has been manipulated, with

How system owners see data

The company resources are:

1. Things essential to the purposes or objectives of the system.

• Tangible things (for example, materials, supplies, machines, vehicles and

How users see the data

How system designers see data

record arrangements, data structures, database schemas, file organizations, fields,

A company's activities are daily processes that

Information systems activities are the processes

1. The provision of data and the processing of information.

2. The improvement and simplification of business activities. Some activities can

How system owners view activities

Business systems functions include sales, service, manufacturing, shipping, receiving,

Objectives are more specific purposes that help achieve goals.

How system users see activities

Users view activities based on different business processes.

How system designers view activities

2.3 LIFE CYCLE OF SYSTEMS DEVELOPMENT

2.3.1 ESSENTIAL PRINCIPLES FOR SYSTEMS DEVELOPMENT.

1. Identify the problem (or opportunity or norm).

6. Design and implement the solution.

Establish Standards for Consistent Development and Documentation: To promote

Systems development standards generally describe activities, responsibilities, guidelines,

3.1 PHASES OF PLANNING

3.1.1 PHASE 1: PLANNING STUDY

systems depends on the quality of the company's planning. Accordingly, information