Sie sind auf Seite 1von 6

Chapter 4

Methodology

The methodology section is the most important part of the protocol. This chapter focuses on
how the research is to be done. It includes discussion on research method and techniques, systems
development methodology, requirements analysis, requirements documentation, design of software,
development and testing, implementation plan and implementation results.

Research Methods and Techniques

This section lists and discusses the specific steps and activities that will be performed by the
researcher to accomplish the project.

 Research methodology. Refers to the techniques that the researcher uses to gather
information. Example: Descriptive, Case Study, Experimental, Documentary Analysis, etc.

Systems Development Process

The systems development life cycle (SDLC) is a conceptual model used in project
management that describes the stages involved in an information system development project, from an
initial feasibility study through maintenance of the completed application.

There are many software development models and methods are available in the market. All of
this models are mentioned below:

1. Waterfall model
2. V model
3. Incremental model
4. Rapid Application Development (RAD) model
5. Agile model
6. Iterative model
7. Spiral model

Requirements Analysis

This section will go over each of the necessary requirements to meet the desired output for the
new system that includes: economic feasibility, operational feasibility and schedule feasibility.

 Economic Feasibility
o Cost Estimate
Is the approximation of the cost of a program, project, or operation.
o Cost Benefit Analysis
CBA is a methodology for assessing the net benefits accruing to society as a whole
as a result of a project, program or policy.

The Cost Benefit Analysis summarizes the revenues and costs involved with the
proposed project.

 Operational Feasibility
o Fishbone diagram
A fishbone diagram, also called a cause and effect diagram or Ishikawa diagram, is
a visualization tool for categorizing the potential causes of a problem in order to
identify its root causes.

The fishbone diagram identifies many possible causes for an effect or problem. It
can be used to structure a brainstorming session. It immediately sorts ideas into useful
categories.

When to use a Fishbone Diagram


 When identifying possible causes for a problem.
 Especially when a team’s thinking tends to fall into ruts.

How to Create a Fishbone Diagram

Creating a Fishbone Diagram involves four main steps. Within those steps,
“bones” are used to indicate the impact of the causes (the weight of the impact is
measured in the size of the bones that are drawn). For instance, the larger bones closer
to the head of the fish represent a big impact, while small bones further away from the
head have a smaller impact.

The four steps include:

1. Determine the Head of the Fish


The head of the fish should be the topic you are analyzing. When creating a
Cause-and-Effect Diagram, the head will be the effect.

2. Determine Related Factors to the Head


Factors are causes related to the topic or the effect. One option is to list the
causes by which have the biggest influence on the head.
3. Determine the Possibility of Grouping Factors/Causes into Categories

Service Industries Manufacturing Process Steps


(The 4 Ps) Industries (for example)
(The 6 Ms)
 Policies  Machines  Determine
 Procedures  Methods Customers
 People  Materials  Advertise Product
 Plant/Technology  Measurements  Incent Purchase
 Mother Nature  Sell Product
(Environment)  Ship Product
 Manpower  Provide Upgrade
(People)

4. Draw the Diagram


 On the right side, write the topic and draw a backbone arrow from left to
right.
 Draw vertical arrows connecting the categories to the main backbone arrow.
When creating a Cause-and-Effect diagram, if you listed the causes by those
that have the biggest influence on the head, the larger bones that are closest to
the head of the fish have the greatest impact and the smaller bones that are
further away indicate causes that have less impact.
 If you’re grouping factors or causes, draw horizontal branching arrows for
each vertical arrow connected to a category. This helps compartmentalize the
individual factors related to the category.

 Schedule Feasibility
o Gantt Chart

A Gantt chart is a graphical depiction of a project schedule. A Gantt chart is a type


of bar chart that shows the start and finish dates of several elements of a project that include
resources, milestones, tasks and dependencies. Henry Gantt, an American mechanical engineer,
designed the Gantt chart.
These charts are useful in planning a project and defining the sequence of tasks that
require completion. In most instances, the chart displays as a horizontal bar chart.

Requirements Documentation

This section presents the initial design of the system by discussing its major components and
their interactions. These components include the software components (e.g. modules, database system,
etc.) as well as the hardware components (e.g. processors, devices, etc.). The components and their
interactions are graphically represented using design tools, such as hierarchical charts, structure charts
or object models. Data flow diagram may also be included to show how information passes among
processes. In addition, discussion on why certain alternative and trade –off were chosen must be
included (e.g. issues on software decomposition, cost of hardware).

The researcher shall identify the needed documents such as forms and reports in accordance
with the requirements of the system.

 Forms
 Reports
 Input – Process – Output (IPO)

Accordingly, correct data, sequence and processes shall be established to provide evidence of
conformity to the system development process.

 Data and process modeling


o Context diagram
It is a data flow diagram, with only one massive central process that subsumes
everything inside the scope of the system. It shows how the system will receive and
send data flows to the external entities involved.

o Data flow diagram


It is a graphical representation of the "flow" of data through an information system, modeling its
process aspects. Often they are a preliminary step used to create an overview of the
system which can later be elaborated. It also shows what kinds of data will be input to
and output from the system, where the data will come from and go to, and where the data will be
stored.

o System flow chart


It is the graphical representation of the flow of data in the system, and represents
the work process of the system. Information system flowchart show how data flows
from source documents through the computer to final distribution to users.

o Program flowchart (transaction)


A program flowchart details the flow through a single program. Each box in the
flowchart will represent a single instruction or a process within the program.
 Object modeling
o Use case diagram
A use case diagram at its simplest is a representation of a user's interaction with the
system that shows the relationship between the user and the different use cases in which
the user is involved. A use case diagram can identify the different types of users of a
system and the different use cases and will often be accompanied by other types of
diagrams as well. Class diagram

o Class diagram **
The class diagram is a static diagram. It represents the static view of an
application. Class diagram is not only used for visualizing, describing and documenting
different aspects of a system but also for constructing executable code of the software
application.

The class diagram describes the attributes and operations of a class and also the
constraints imposed on the system. The class diagrams are widely used in the modeling of
object oriented systems because they are the only UML (Unified Modeling Language)
diagrams which can be mapped directly with object oriented languages.

o Sequence diagram **
A Sequence diagram is an interaction diagram that shows how objects operate with
one another and in what order. It is a construct of a message sequence chart.

o Activity diagram **
The Activity Diagram can help to describe the flow of control of the target system,
such as the exploring complex business rules and operations, describing the use case also
the business process.

The focus of activity modeling is the sequence and conditions for coordinating
lower-level behaviors, rather than which classifiers own those behaviors. These are
commonly called control flow and object flow models. The behaviors coordinated by these
models can be initiated because other behaviors finish executing, because objects and data
become available, or because events occur external to the flow.

Design of Software

This section discusses the design and implementation of the major data structures and
algorithms used in the software. It included a discussion on the major issues and problems
encountered, and the corresponding solutions and alternatives employed by proponent. Parts of the
design tools in the Technical manual may be lifted as figures in this section.

 Data Design
o Entity Relationship Diagram
ERD or Entity-Relation Diagram is a specialized graphic that illustrates the
relationships between entities in a database. ER diagram soften use symbols to represent
three different types of information. Boxes are commonly used to represent entities.
Diamonds are normally used to represent relationships and ovals are used to represent
attributes.

o Data Dictionary
A data dictionary defines the structure of the database itself and is used in control
and maintenance of large databases. It helps various users to know all the objects which
exist in the database.

 System Architecture (if applicable)


o Network model
o Network topology
o Security

Das könnte Ihnen auch gefallen