Professional Documents
Culture Documents
General Ledger 07a v04
General Ledger 07a v04
1.0 Introduction
A general ledger manages all the accounts for recording transactions relating to a
company's assets, liabilities, owners' equity, revenue, and expenses. In modern
accounting software or ERP, the general ledger works as a central repository for
accounting data transferred from all sub-ledgers or modules like accounts payable,
accounts receivable, cash management, fixed assets, purchasing and projects. The
general ledger is the backbone of any accounting system which holds financial and nonfinancial data for an organization. The collection of all accounts is known as ledger
account.
1.1 Problem/Opportunity Description
Its not easy to record all data in a manual process. It can take more time to write
all of this in a record book. Calculating a whole module in a manual process is not easy
to be done.
In General Ledger System, recording a data coming from other sub-system can
be done by its automatic process. Gathered data are automatically identified if it is
assets, liabilities, owners equity, revenue or expenses. Calculating of weekly and
monthly records is done by this system.
1.2 Benefits
The system for the GL will be able to secure data records, especially Contracts.
It can also provide accurate and reliable data to avoid any conflicts for both parties.
And it will be much easier for the company and the administrator themselves to transmit
data gathered from all the sub-system to the general ledger itself. The report will
accurately done by the general ledger.
Page 1
1.3 Goal
To create a system that will manage all the specific data gathered from all the
sub systems. To make it computerize and to add more convenience in the transmission
of all data gathered.
And to create a system that will fit to the needs of the general ledger that can
provide solutions, that will help the current situation of companies and to provide a
system that will cater the process of organizing and securing data of contracts.
1.4 Stakeholders
The accountant and the management of that Company because they are
their company.
The project team because they are the one who will going to solve the
problem of the company.
Page 2
Update
Edit Chart
of Breakdown Structure
Work
General
Ledger
Edit Ledger
Transaction
General
Ledger
GENERAL LEDGER
Journal
MENU
GENERAL
Edit glAcct
File
Verify
Ledger
Edit glCode
MONTHLYDataFile CHART OF
MONTHLY
REPORTS
UPDATES
ACCOUNTS
MISCELLANE
OUS
FILE
EDITORS
Account Trial
Balance
Create
Edit glTran
Opening File
Entries
General
Ledger
Analysis
Statement
Balance
Sheet
Income
Statement
Invoice to
G/L
Update
Receivabl
es to G/L
Update
Rent/Leas
es to G/L
Update
PayablesMENU
GENERAL LEDGER
to G/L
The EDIT LEDGER TRANSACTIONS program is used to add, change, view or delete
Update
any transaction
in the ledger database.
Payroll to
G/L
Accounts
The Account Trial Balance lists ledger transactions by account in chronological order
Chart of
Page 3
Page 4
Batch posting totals maintained throughout the editing session, with warning
generated if attempting to leave program out of balance.
Audit journal produced at end of editing session.
The GENERAL LEDGER JOURNAL provides a list of ledger transactions in journal
(numerical) order.
The Account Trial Balance provides a list of ledger transactions by account, in
chronological order with account subtotals.
The General Ledger Analysis provides a list of each account balance in a monthly
spreadsheet. Balance Sheet and Income Statement subtotals are included.
Detailed mode: Lists transaction ID, date, account, debit and credit and balance
amounts, and description for each transaction.
Summary mode: Lists debit and credit totals only.
Output can be directed to the screen, .PDF preview, any printer, fax, email or a
networked Hard drive on the server.
EDITING SCREEN: EDIT LEDGER TRANSACTIONS
1.2.1 Objective
- To create a cost efficient system that will be easy to understand, reliable and that has
user friendly interface for every accounting department of a merchandising special the
general ledger.
- To create a system that has ability to integrate unto the other subsystems of the
merchandising.
Page 5
- To create a system that will be capable in handing accurate data that will help the
company in terms of efficiency.
- To create a fully documented project that will include the plans, processes,
implementations whether in terms of changes or if there were standards that must be
applied.
2.2 Deliverables
General Ledger Menu
Project Deliverable
Edit Ledger Transaction
Work Products/Description
To change and update.
Monthly Reports
Project Deliverable
General Ledger Statement
Balance Sheet
Income Statement
Work Products/Description
To record all of the transaction of the GL
To summarize the financial balances.
To shows the companys revenues and expenses
Monthly Updates
Project Deliverable
Update Invoice to G/L
Work Products/Description
Program updates a selected range of invoices as a
database.
Program updates a selected range of rent/leases
invoices as a transaction in the General Ledger
database.
Program updates payables transactions (vouchers and
checks) for a given period as a transaction(s) to the
General Ledger database. The resulting G/L Transaction
Page 6
will
Update Payroll to G/L
be
distributed
to
the
appropriate
G/L
Account/Subsidiary code.
Program updates a selected range of payroll checks as
a transaction in the General Ledger database.
Chart of Accounts
Project Deliverable
Edit Chart of Accounts
Work Products/Description
Program allows the user to add, change, view or delete
Mobile Apps The mobile apps for the accounting in general ledger
will be planned to have a mobile application for the android mobiles for
information.
Personalized Screen- there were planned general design for every
subsystem however the proponents are given a chance to personalize
the screen to add more creative design personalized by the developer.
Page 7
Import Export- the system data must also be able to adapt into other
application such as MS word, Excel and other more applicable
devices.
Testing
The test plans are conducted through different laptops at a different
operating system to make sure that the system will be capable in adapting
unto the clients location. It can also be done through measuring the
system functions if every program within the system are functioning well.
DATE
June 27, 2014
Group meeting
Start
3pm
Finish
6pm
Duration
3hrs
July 5, 2014
Brain Storming
7pm
6am
11hrs
July 8,2014
Distribution of sub-system
3pm
6pm
3hrs
July 9, 2014
4days
Company search
5days
2days
Page 8
7 August 2 ,2014
8
9
1
0
11
August
11,2014
August
17,2014
September
17,2014
October 5,
2014
Oct
2
1
21-28,2014
Nov
3
1
3-10,2014
Nov
4
1
12-26,2014
Dec
5
1
1-31,2014
Jan
6
1
1-15,2014
Jan
7
1
17-24,2014
Feb
8
1
1-15,2014
Feb
9
2
17-24,2014
Feb. 24 Mar.
0
2
21, 2014
Mar
23-28,2014
3Days
Chapter 1
2week
Chapter 2
3week
Chapter 3
2week
2week
1week
1week
2week
Start Programming/Documentation.
1month
Coding
1week
Test run
1week
1week
1week
1month
Defense week
1weeks
The project for the General ledger is considered a successfully done if the
documents and systems had passed the standard implemented for the project.
The project will be considered a success if the system is functioning well and
were able to cater transactions, generate accurate reports.
Page 9
The project is success if the system met the requirements of the users. User is
an important part of the system, thus this project must conform to the needs of
the user to be considered a success like taking the side of the future user of the
system the developer must acknowledge not just the process but the outer look
of the system it must not irritate the eye of the user or it must not be destructive
to the eye of the client.
Probability
Impact
Risk Management
(H-M-L)
M
(H-M-L)
H
Action
To make sure that
The outcome of
the project
greatly depends
Page 10
on the people
on the project
assigned to
complete it
H
Failure to
and hardware
program/run the
system due to
have decide to
software/hardwar
always prepare a
e issues.
Shortage of funds
documentation
For the funds, the
unable to comply
team decided to
necessary
requirements
technology-
be pure
dependent
technology base
so if ever there
will be problems
when it comes to
the devices and
Page 11
equipment, the
developer
suggest that the
company must
have its own
technical support
to trouble shoot
the problem
Work Plan is not
The proponents
met due to
unexpected
do the project so
events resulting
there will be no
to delayed
expected delay,
completion of
but if in case
this project.
project.
Team works
together as a
other modules
whole so it is
under
merchandising
team to have
system.
integration problem
thus, but it can, so
the whole team will
conduct integration
test 2 weeks
before the final
Page 12
Page 13
Front End The proponents will be using Java Netbeans IDE 7.4 for front
end since the lead programmer is well knowledgeable in using this kind of
Responsibilities
Information
Elmer Tabin
Serve as
ultimate
authority/
responsibility
for the project
Provide
strategic
direction and
guidance
Approve
changes to
scope
Business Analyst
Rowel Cabalan
Identify and
secure funding
Make
business /
Approach
decisions for
Page 14
Time
the project
Participate in
key activities
Make resources
available
Approve work
products
address issues,
and approve
change
Project Manager
requests
Report to and
receive
direction from
sponsors
Manage,
review, and
prioritize project
work plans
Provide status
reports
Manage project
team
Recommend
changes,
escalate issues,
and mitigate
risks
Participate in
Elmer Tabin
Members
Jenelyn Arquiza
project
Rowel Cabalan
activities,
Page 15
including
planning,
implementation
of deliverables
and quality
control
Advisors and
resources
PROJECT BUDGET
Budget Item
One-Time Costs
One-time item 1
Ongoing Costs
Ongoing item 1
Description
Description
Total One-Time Costs
Description
Total Ongoing Costs
Page 16
Budget Cost
Page 17
guideline to understand the succeeding chapters. Below are the different researched
literature and studies that will establish the knowledge of the readers.
Page 18
stored in this system. Some of the data is fed to the GLS from other financial
systems, as depicted on the chart below, while other data is entered directly into
the GLS system via on-line screens. This User's Guide should provide you with
the information necessary to use the University Financial Accounting System and
the GLS. Under the integrated system there are 8 subsystems also called
Subsidiary Ledger. Before getting the general ledger report which is the last part
of the integrated system, the subsidiary ledger must be complete and updated to
make the report accurate. The account code structure at LSU consists of two
different types of accounts; a general ledger (G/L) account and a subsidiary
ledger (S/L) account. The general ledger accounts are further divided into three
types; assets, liabilities and mapping accounts. Each of these types of accounts
is explained in detail in the pages that follow. A separate G/L mapping account is
established for each fund/campus, or for each entity within a fund for which fund
balances are maintained or for which separate financial statements are needed.
Each S/L account is "mapped" to a specified G/L mapping account, and all
budget, encumbrances, revenues, expenditures and pre-encumbrances in S/L
accounts are recorded in summary in the G/L mapping account. Each S/L
account maps to a single G/L mapping account while one G/L mapping account
represents summary information for a group of related S/L accounts. Summary
entries to these G/L mapping accounts are system generated and are not the
responsibility of the personnel in the departments. To determine the mapping
account for a specific S/L account, view the "Basic Account Information" in the
Chart of Accounts (COA) system. See the appropriate section of this guide for
how to use the COA. The LSU Chart of Accounts system (COA) was developed
to maintain the University's valid general ledger and subsidiary ledger account
numbers. These numbers are structured nine digit numbers that are unique
across the system. The account structure section of this guide explained in detail
the meaning of the digits and the relationship between subsidiary ledger and
general ledger accounts. This section of the guide is provided to aid the user in
how to inquire into the COA and to interpret the information. There are two
different menus that relate to the University account numbers. The first is the
Merchandising (General Ledger)
Page 19
COAMENU which is used to inquire into specific accounts and review the
attributes associated with specific accounts. The second is the COA/GLS MENU,
which is used to review the relationship that has been established between an
account number and specific objects, transaction types and project numbers.
There are many options available from this menu. Begin by typing the Account
Type (G or S for general ledger or subsidiary ledger accounts), the nine-digit
account number, and the appropriate fiscal year. If fiscal year is not entered, it
will default to current fiscal year. The first three options provide the user with
screens displaying the attributes that have been established for an account. For
example, the Basic Account Information screen shown on the next page
displays the account title, distribution code, begin date, expire date, and other
generic account information normally captured on most University accounts.
URL: http://www.fas.lsu.edu/acctservices/forms/far
3. University of Wisconsin Financial and General Ledger system
The General Ledger module is the core of the SFS system. Many of the tables
set up here are used by other modules throughout the system. This is where data
from all modules comes together and where most of the financial reporting is
done. Ledgers store posted general ledger journals for a set of Chartfield values
by accounting period and fiscal year. The admin represent a set of books for
each business unit and are usually populated by journal entries. There are
several ledgers that are delivered with the SFS system. Most campuses are
currently using the actual ledger, which stores all transactions except budgets
and the student budget Ledger, which stores budget information. Before looking
at the ledger the user must familiarized itself in the unique chart of fields and
different acronyms that the admin provided. In order to understand the flow of
processing general ledger reports, the business process of the system is
included as well as screenshot of different forms.
URL:http://www.uwsa.edu/fadmin/sfs/glddict
Merchandising (General Ledger)
Page 20
Page 21
system
was
managed
by an Accounting
staff,
trained
at the
Page 22
Data Processing (EDP) came into form as a section unit of the Finance Division;
with the Accounting staff manning the section and the Assistant Financial
Controller as the Head. This also marked the start of the Local Area Network
environment in the hospital. The main focus of the EDP operations at that time is
in the DOS base financial applications covering General Ledger, Billing, Check
Vouchers and Payroll modules.
URL:http://www.maniladoctors.com.ph
Page 23
very flexible for hospitals use. There are many type of earnings, pay periods,
multi-company, and user defined accruals of benefits. The hospital defines their
deductions and accrual of additional compensation. The payroll checks are
printed on a laser printer which includes signatures and bank routing information.
Also available as a standard feature is direct deposit. The system produces all
required state and federal reporting. As part of the pay period processing, all
financial information is interfaced to general ledger with accrual data, and
automatic reversal of the accrual data the next general ledger period. The system
contains history databases of all employees pay information for each check/direct
deposit issued. There is also a history database of each pay period labor
distribution for each division, department, and position the hospital has defined in
their payroll. The personnel system allows for personnel actions to be
documented on the employee record. The system tracks licenses, leave, physical
examine, education, and user defined fields for tracking. The Depreciation
application is an addition to the general ledger system, and will track the
depreciation of any asset of the hospital. There a many conventions and
methods to select from for deprecation of the assets. The application tracks book
value and tax value if the user chooses these options. The depreciation is
calculated each month and posted to general ledger. As new assets are added
during the year, they will be calculated based on the method and convention
selected and posted to general ledger. Assets are tracked by division and
classification. Material Management application will maintain inventory for multi
departments within the hospital. The system can track both billable and nonbillable inventory items. The purchasing can process both inventory and noninventory items. The system also tracks inventory uses by department and
maintains a stock level for each hospital departments. The system generates
automatic re-orders based on information on each item. Physical inventory can
be done at any time, or as many times during the year the users chooses. The
material management department can continue to operate during physical
inventory and when the reports are produced will calculate any activity that
occurred during that taking of the physical inventory.
Merchandising (General Ledger)
Page 24
URL :http://www.winmedhis.com/financialsystems
3. Center for Medicare and Medical Services
The Centers for Medicare & Medicaid Services (CMS) has implemented the
Healthcare Integrated General Ledger Accounting System (HIGLAS). HIGLAS is
an integrated, dual-entry, general ledger accounting system to manage
healthcare outlays. CMS has 45 million providers and beneficiaries, and it uses
HIGLAS to process approximately 4.5 million claims daily. HIGLAS improves
accountability for Medicare payments to physicians, hospitals, and other
providers servicing Medicare beneficiaries. HIGLAS is also used to support
accounting for Medicaid and Childrens Health Insurance Program (CHIP) grants
and to generate the CMS Financial Statements, including all vendor payments,
payables, and receivables.
Page 25
Medicare
Contractor
accounting
systems
with
single
Improve
accountability
for
Medicare's
payments
to
Page 26
URL:http://www.cms.gov/
4. P2 energy solution
EXCALIBUR Financial System is a powerful and comprehensive General
Ledger module is a flexible accounting and reporting system with special
emphasis placed on the requirements of the oil and gas industry. All
financial transactions entered or created in other Excalibur systems
automatically flow to the General Ledger. The General Ledger system
contains extensive standard financial reports and also allows you to
customize financial reports to your specific requirements: Journal Voucher
Data Entry Features, Duplication features to speed data entry, Unlimited
detail transaction descriptions, Copy feature for automatic duplication of
any current, historical or template journal voucher, Autoprompt feature for
changing voucher detail line amounts only while leaving all other coding
intact, Reversal feature for automatic reversal of any current or historical
journal voucher, Accrual feature for automatically creating reversing
journal vouchers in a user-specified accounting period, Recurring feature
for automatically creating duplicate journal vouchers in any number of
user-specified accounting periods, Journal voucher upload functionality
from Excel template, Internal and Accounting Controls, Flexible chart of
accounts structure to accommodate company preferences, Balanced
journal entries are required (one-sided or out-of-balance entries are not
permitted) Automatic generation of intercompany payable and receivable
entries Journal voucher review/approval required, at your option, prior to
Merchandising (General Ledger)
Page 27
Page 28
and
Department
Management
of
Finance
(DBM),
(DOF),
Commission
Bureau
of
on
Audit
Treasury
(COA),
(BTr),
and
of a
Government Integrated
Financial
Management
is
being
implemented
by
the
GOP.
URL:http://pfmp.org.ph/index.php/overview
2.2 Related Study
2.2.1 Foreign Study
1. General Ledger associates streamlines a shipping company
The client's internally developed operational systems each had its own
supporting financial system. It had separate accounts payable systems to
pay for terminal and depot expenses, truckers, agency commissions,
repair work orders and administrative expenses. Plus there were separate
accounts receivable systems for shipments originating overseas and for
those originating domestically. Separate, internally developed general
ledgers were maintained for corporate and the operating units. While
these operating ledgers satisfied financial requirements they were of little
value to the operating regions that maintained their own expense analysis
Merchandising (General Ledger)
Page 29
systems. The task for GL Associates was to integrate all these systems
into one compliant financial systems product. First, we implemented new
corporate accounts payable and general ledger systems by designing a
new corporate chart of accounts (COA) and table of organization. New
"coding structures" supported an annual budgeting cycle even before we
implemented the new corporate ledger. This was especially critical, as the
company had started a major reorganization that was not supported by the
existing budgeting process. Next, we implemented the new corporate
ledger and accounts payable systems. These contained a level of
reporting detail and drill-down capabilities that far exceeded those of the
legacy system. We then put into place the financial systems for the
operating regions. This involved redesigning the COA so that it provided
financial reporting and meaningful analysis to operational personnel. It
was implemented concurrently with the elimination of all legacy accounts
payable systems and the accounts receivable system for domestically
originated shipments. The implementation was unusual because of the
large number of interfaces to legacy operational systems that had to be
built, the need to reassign vendor codes and the conversion of multiple
payable files, each with its own format. It also had to satisfy complex
accrual requirements to account for extensive delays in before
submissions of invoices by terminals, depots and truckers. The
streamlined systems developed by GL Associates greatly reduced the
need for internal training, eliminated most of the previous system
maintenance efforts, consolidated bank accounts, accelerated the closing
cycle and provided management with more meaningful financial reporting
and greatly enhanced analytical capabilities.
URL:http://www.glassoc.com/resource_center_case_studies.php?id=2
2. Kuali Financial System Implementation Project
Page 30
Page 31
URL:http://www.vivantech.com/case-studies/case-study-kuali-financialsystem-implementation-project
Page 32
entry areas for account rules, instructions and adjustments. The system
also has extensive reporting capabilities including a tool for producing
custom ad hoc reports. GL Associates relied on Microsoft technologies to
implement what was an n-tiered solution. We started with a Microsoft SQL
Server database that we populate nightly from the clients mainframe
system through IBMs MQSeries for Windows NT. In the middle tier, the
business processes were implemented using COM objects developed with
Microsoft Visual Basic and managed by COM+. Web pages that comprise
the systems top tier are Active Server Pages. During the day MQSeries
was also used to perform interactive messaging with a number of backend custody and trust accounting systems.
URL:http://www.glassoc.com/resource_center_case_studies.php?d=7
4. General ledger associates provides the right formula to solve
accounting crisis
The post-merger company found itself with over 40 separate general
ledger databases, one each for its various plants, divisions and corporate
entities. The general ledgers used different Charts of Accounts (COAs)
operated on different software products that ran on diverse hardware
platforms scattered across the country. Further complicating the situation,
the corporate ledger interfaced to yet another software product that
provided consolidation and corporate reporting. Divisional summary data
entry into the consolidated ledger was time consuming. Last minute
budget changes and adjusting entries resulted in significant discrepancies
between plant/divisional, corporate and consolidated ledgers. Frequent
business unit restructuring made ledger maintenance extremely difficult.
Month-end general ledger runs took many hours with out-of-balance
conditions frequently occurring. The various COAs not only were
incompatible but also were applied inconsistently and could not
Merchandising (General Ledger)
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
1.0 Introduction
The Risk Mitigation, Monitoring and Management plan is about looking forward for
the possible circumstances that may occur within the development cycle of the
project. In this section the proponents prepares a list of the possible risk that may
affect the implementation of the system with the solution for that risks and also
blocking the away the risk even before it comes.
1.1 Scope And Intent Of RMMM Activities
The scope of the system is all about the management of the general ledger,
this includes all the companys report that has to do with all the necessary
and important files that the ledger must took good care in order to maintain
the balance within the whole company and in order to do that the developer
must possess a good relationship with the client to clearly know the business
processes of the GL so there will be no problem regarding the business
transaction of the company. In this case the scope also of the risk mitigation,
monitoring and management has been clearly stated, its boundary is the
overall scope of the general ledger of the merchandising but not involving the
operation of the other sub-systems with the ledger.
1.2 Risk Management Organizational Role
Creating a project has a need for a team work this includes choosing a
team member that are all good in functioning to suit all the needs of the
project.
Everyone in the group must know their specific function and in this section
the proponents will state all of the person associating the project and their
possible contribution to avoid risks.
Page 39
Page 40
Employee risk -The outcome of the project greatly depends on the people
assigned to complete it
Process risk- Failure to program/run the system due to software/hardware
issues.
Financial risk- Shortage of funds unable to comply necessary requirements
Technology risk- The system will technology-dependent
Business Risk- Work Plan is not met due to unexpected events resulting to
Page 41
Employee Risk:
Employee risk is about the software development team their
functions and the possible risks that they may encounter in the
development process.
Process Risk:
Process risk is about the client willingness to share information
about their company, that if they fail to give the exact transaction of the
product then the whole system will be useless.
Product Size:
Knowing the exact size of the product is one of the big matters to
be considered this includes learning how to over-estimate the project to
avoid problems on the storages of data gathered.
Technology Risk:
Technology risk is keeping your eye with what is latest and what are
the softwares that cannot stand for several more years, this is also very
important to consider to prevent technical problems.
Page 42
Category
Risks
Probability
Impact
Employee Risks
40%
Process Risk
35%
Product Size
30%
Development Risks
Insufficient resources
30%
Customer Risk
20%
Technology Risk
Obsolete technology
10%
Business Impact
10%
Description
Catastrophic
Critical
Marginal
Negligible
Page 43
Page 44
software that the proponents use for the system can no longer
manage to be in the industry for several more years, so the
developer must know all the updates regarding the changes in the
software world.
3.1.5 Development Risks
Not all system are perfectly independent, there are some
systems that alone cannot manage all security that leads in
providing other equipments, this section will tell the risks in not
providing appropriate tools and equipment to make the system all
set.
3.1.6 Employee Risks (Teammates)
The development team themselves can also be a problem
by having lack of knowledge about the system that they are going
to create this can really make mistakes most especially if the
developer doesnt really aware of using the software that the
company is using this could take a lot of time to look on how they
are going to create the project.
3.2 Risk Monitoring For Risk Management
Since the possible risks has been assumed, in this section the proponents
will now going to monitor the system development to avoid and to prevent the risks
from entering the system.
Page 45
will be any changes so that adjustment would be much more easier for the team if
ever there will be any.
3.2.2 Business Impact
Business impact includes taking look at the both sides the business process
of the system and of course user of the finished product. In order to provide their
needs the developer must spend more time with the user to know all the needs of
the user and all transaction that the user is handling.
3.2.3 Customer (User) Risks
To avoid having trouble with the user in the completion of the system, the
proponents must know all the transaction that the general ledger is doing in order
to provide good quality product.
3.2.4 Process Risks
Since the proponents goal is to provide quality assured product, they must
set up a goal guide line to be followed by the team in order to complete the project
sticking to the goal.
3.2.5 Technology Risks
To avoid having trouble with technology one member of the team must be
the one to look at every update of the software and look at the possible software
that can adapt to the current system that you were working.
3.2.6 Development Risks
Tools and equipment in bringing the quality of the product is a must so the
team must determine all the needed tools and equipment and give the customer
options of the equipment based on the price and quality and explain why the
system needs that and tell them some pointers and idea so that they know what
will happen if they fail to provide the equipments. Give them options so that the
customer can still choose what is best for their system
Merchandising (General Ledger)
Page 46
Page 47
Base on the plan, the proponents will going to meet the customer every
week so he could monitor the development of the project so in this case it is really
impossible to have problems with the customers opinion, and if ever there will be
minor problem that the customer find in the system, then there is nothing to worry
because the proponents will going to have a help and guideline on how the
customer will trouble shoot the problem.
3.3.4 Process Risks
The process risk is about risking the quality standard. If the team still fails to
provide the quality standard that the company is looking for, then this will going to
be the time to give more focus on the transaction process of the company, assign
again different group member to analyze the business process of the company to
meet their quality standard.
3.3.5 Technology Risks
If the technology still becomes a problem then the team must go on a trial
and error method to see if there is any software that their system can adopt in
developing their system.
3.3.6 Development Risks
If the team encountered financial shortage regarding tools and equipment
that must be added to the system, provide the client options in the equipments and
tools. This includes the functionality, price, quality of the product.
3.3.7 Employee Risks (Teammates)
It is not really impossible to dont encounter a employee risks, because it is
really hard to be consistent, but if the team member still be the problem then, ask
them about how they feel or if they are having problem with their tasks, helping one
another will be a great help to accomplish everyones task.
4.0 Special Conditions
Merchandising (General Ledger)
Page 48
The PC
The system that the proponents proposing must be adoptable to other
computers it must be running even in the clients facility, in case that the
application have already installed to the clients computer and they find it a
problem for the employees to use the software, then the developer will request to
Page 49
In creating a system there will always be a change and we cannot control it not to
happen, so in this project the development team decided to create a software
configuration plan to identify, control, and make sure that the plan is implemented
correctly.
1.1 Scope And Intent Of SCM Activities
The scope of the Software Configuration Management plan is only within the
boundary of the GL, Its main purpose is to collect data so it must be accurate,
in this section the proponents will ensure that all of the data gathered are
collected by the system accurately, and this will be properly solved if the
system is already working well so the purpose of SCM activities is if ever that
there were changes to be implemented within the development of the system
all of the changes will be controlled since there were all be identified and using
this SCM the proponents can make sure that all of the changes will be
properly implemented because everything will be documented.
1.2 SCM Organization Role
The development team is just composed of a small team so all the team
member agreed to accept responsibilities most of all if within the changes.
Everyone must be working to aim the goals of the team. There will one group
member to analyze all the must be changed modules inside the system and
one to check all the changes implementation and the others are the one to
record and monitor all the changes all of the changes are being decided by
the whole team and let it check by the adviser to know if he already approves
it.
2.0 SCM TASKS
In this section we will be describing the software management configuration plan in
detailed form. In this section all the task will be describe and will be assigned to the
group members. The clients will also be updated from any changes that the
proponents will be implemented but we will make sure that this changes will not
Merchandising (General Ledger)
Page 50
affect the users and if in case the changes affect the use of software , it will be
discussed with the entire team to the clients team in the meeting.
2.1 Identification
All of the software configuration will be describe and identified and will be
used for the software configuration management plan.
2.1.1 Description
Identify change
In the development phase of the system the team must work to identify all
the changes they have figured out in the system and ask all their
suggestion if they are agreed to implement change as well.
Approve change
The system likes to make sure all the changes of the software will be a
great help for the system. So we will be having rules for the changes, and
one of those is one can never implement changes in the software without
any consult and permission from team members.
Ensure that change is being properly implemented
The team will going to check if the changes are properly implemented
without causing troubles to the other parts system.
Page 51
Page 52
Page 53
Page 54
development team is only a small group the proponents will find a way to
communicate to other team members regarding the changes that they plan to
implement.
Description
Verbal Communication
Aside from the technical and computer base communication, since the
group is only small we will still be implementing a verbal talk which is
done every meeting.
Page 55
This will be helpful for all of the clients if ever the software is already
delivered, the online help desk will be very useful for trouble shooting
the software without a need to call for a programmer.
Emails
Emails can also help to keep in touch with the developer in the long
time process of using the software.
Suggestion notes
Suggestion notes will also be reviewed for developing the system.
Page 56
To make sure that the team is still meeting the quality standard that tey are
aiming.
Page 57
Here the lists of ISO 9001 quality standards that must be applied to the
software by the software engineering, these are the 12 requirements
delineated by them and the proponents would like to apply it as their quality
assurance.
-Management responsibilities
-Quality system
-Contract Review
-Design Control
-Document and data control
-Product Identification and trace ability
-Process control
-Corrective and Preventive action
-handling storages
-control quality audits
-training
-Servicing
-Statistical Technique
3.1.1 Conduction a Review
The proponents will going to conduct a review regarding the changes, if the
changes may affect the client, then the changes will be discussed first to the
client and must consult first to the other team mates.
3.1.2 Roles and Responsibilities
The proponents decided to distribute the work to the five team members of
the team and give their specific work fields.
Page 58
Page 59
The team will going to monitor every one and will going to have weekly report of
everything that will be done.
The members will going to note their part of the system and interfaces and their
share between the members.
All the changes that the system will be implemented will be consulted first to all of
the team members before doing any changes.
Page 60
Page 61
Page 62
Ego-Less Structure
Editor/Teste
r/
maintenanc
Conceptual &
Advance Interface
Development (1)
User Interface
Design &
Development
Unacceptable Range
100
0 Merchandising (General Ledger)
1
time
Page 63
3070
time
401000
times
Acceptable Range
for Errors
1540
100
10
tim
1
0
3-6
time
s
Req.
Design
Coding
Dev. Test
System Test
Field Operation
The Relative Cost of Correcting errors that must be done are visually explained at the
above Figure. The proponents have declared the expected error graph ranging from 1
time error to 40 to 1000 errors.
Page 64
-this is to form a good communication with the client, In this case all of the sharing of
information will be easier since the development team and the client always talked.
- Extensive detail design
-it is also included to have a system detailed design just like the actual but more
efficient.
- Research on the subject
- The development team must be willing to research on the subject to know more about
the project.
2.1 Task Overview
This section involves all the assurance within the general ledger system, the
quality control, design and to save time and costs and to minimize errors, problem
tracking and data flow.
2.2 Standard, Practices and Conventions (SPC)
The proponents chose to use a voting system for every decision that they are
going to implement, there will no leader and super visor but everyone must work
according to their specific tasks. And if in case there will be any changes, it will be
discussed first within the team members. Aside from the teams decision the proponents
are also acknowledging the clients opinion so there must be a close contact with the
client not just for a good relationship as partners but also for the discussion of the
extensive detailed design that will be implemented into the system.
1.3 SQA Resources
There will be no external resources are defined for this project.
4.0 Reviews and Audits
This involves all of the formal technical reviews of the software quality assurance
performed of the software engineers. this are the objectives of the formal technical
review.
Page 65
Page 66
The team will going to monitor every one and will going to have weekly report of
everything that will be done.
The members will going to note their part of the system and interfaces and their
share between the members.
All the changes that the system will be implemented will be consulted first to all of
the team members before doing any changes.
After presenting the changes in the team members, the client should also know
the changes made. Clients will be notified for small changes, while an agreement
between the client and the development team should be made for major
changes.
Past and revised versions of the project will also be recorded. The documents
will be noted to identify what kind of revision was made and by who.
Page 67
Page 68
Although hundreds of different errors can be uncovered even for a small scale project
like this all can be tracked to one ( or more ) of the following causes.
Error
IES
No.
Serious
%
No.
MCC
VPS
EDR
IMI
EDL
IET
IID
PLT
Page 69
Moderate
% No.
Minor
% No.
Ei = the total number of errors uncovered during the ith step in the
software engineering process.
Si = the number of serious errors
Mi = the number of moderate errors
Ti = the number of minor errors
PS = size of the product.
The above table and functions will be used in the future, since we dont
have enough data to support it yet.
Customer
Characterist
ics
Process
Technology
Business
Condition
s
People
Environment
Page 70
Product
3. The number of errors and defects in each category are counted and ordered
descending order.
4. The overall cost and defects in each category is computed.
5. Resultant data are analyzed to uncover the categories that result in highest cost to
the organization.
6. Plans are developed to modify the process with the intent of eliminating (or reducing
the frequency of occurrence of) the class of errors and defects that is most costly.
The graph below illustrated the errors that we expected for the project. They
categorized in six fields:
Field
Logic
%
30
Reason
None of the member have any experience on doing a project this size,
Interface
25
Data
15
Handing
Error
10
checking
HW/SW
Standard
10
10
And the queries that the database used are pretty much outdated.
We practically proud of this field because for the job in this size
Page 71
Data
Logic
Logic30%
30% Handli
ng
Stand
15%
ard
15%
Page 72
being followed by the quality managements. But still having problem about the time and
size of the team for the over lapping of the functions of every member.
SYSTEM SPECIFICATION
1.0 Introduction
A general ledger manages all the accounts for recording transactions
relating to a company's assets, liabilities, owners' equity, revenue, and expenses.
So the system must make sure that everything will fall into its proper
specification.
1.1 Goals and objectives
The projects aims to provide solutions that will help the current situation
of companies in terms of general ledger.
The project aims to promote the efficiency of using technology on
companies to improve its productivity, most of all in the accounting
department.
Page 73
3. Training Training that will be provided into the users of the system
4. Mobile Apps ability of the system to be adoptable into mobile such as
android phones for the easily browsing of information of the GL.
5. Free Format Query ability of the system to have a easy query box that can
ensure the easily querying of information that has been encoded in the
system.
6. Personalized Screen to create an personalized and creative attachment to
the created system but not over reacting in to the eye of the possible user
7. Import Export ability of the system to share resources like transferring the
data unto other equipments and windows such as printers and Microsoft
offices such as excel and power point and Microsoft word.
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79
Page 80
Page 81
Page 82
Page 83
Page 84
Page 85
Page 86
Page 87
into other application such as microsoft word, excell and other equipments .
1.3 System Context
The system that the proponents proposing for the accounting general ledger can
be used for a larger departments such that can able to adapt to any location
within the company and be used by multiple user.
It can provide the user efficiency when it comes to faster transaction of the
accountants and would provide reliable data and security to all of the gathered
information.
1.4 Major Constraints
Time
Time-one of the biggest constraint is the time where in the proponents is just
given a short time to search and interview all the necessary details that the
system must adopt. The system for the general ledger is very important for, it
was the one who handles al the report from the whole company, in this case the
developer must be well knowledgeable about everything that will be implemented
inside the software it must provide all the needs of the company for the general
ledger.
2.0 Functional Data Description
2.1 System Architecture
2.2.1 Architecture Model
Page 88
Page 89
Page 90
Page 91
Page 92
Page 93
Page 94
Test Specification
1.0 Introduction
This section provides an overview of the entire test document. This document describes
both the test plan and the test procedure.
1.1 Goals and Objectives
Overall goals and objectives of the test process are described.
1.2 Statement of Scope
A description of the scope of software testing is developed.
Functionality/features/behavior to be tested is noted. In addition any
functionality/features/behavior that is not to be tested is also noted.
1.3 Major Constraints
Any business, product line or technical constraints that will impact the manner in which
the software is to be tested are noted here.
2.0 Testing Plan
We want the product to be bug free. We also want to make sure that there are no
defects in the product. So we will be spending large amount of the total software
development time on the testing. Below is the description of the testing procedure and
strategy. We will also be presenting the timing and scheduled of the tests to be carried
out.
2.1 Software (SCIs) to be test
2.1.1 Interfaces
Page 95
Page 96
Page 97
Page 98
Page 99
Page 100
The test primarily be carried out by the programmer who designed and implemented the
module. Lead tester will carry out test on the modules to finalize the testing.
2.2.2 Integration Testing
In this method of testing we will implement the software at the clients location and will
run it. So we will be testing the product on clients network. As art of testing, will be
looking for any signs of the collision between our software components and those of the
clients. We will install the software at the clients site and will run it. We will have several
different other applications open as well. This applications will be the once that have to
interact with our software on normal bases. We will make sure that all the data is saved
correctly and there is no loss of data or database anomalies in the product. We will be
carefully looking for any sort of collision between several different applications.
2.2.3 Validation Testing
In this method of test we will be working with the customer to find out if the software
developed in valid for the clients. We want to make sure that the client is getting what
he asked for. We will look at the software requirement document in the case of conflict
or misunderstanding with client regarding software components.
We will perform the black box testing where the software is completed and we test all
the software components together. We will have several input data or test data that we
will derive results for. We will insert this data in the software and will get results from the
software. We will compare the results from the software with the results that we derived.
This way will check for the validation of the software.
2.2.4 High-Order Testing
Recovery Testing
No Recovery testing will occur. While system failures are undesirable, termination of the
program in the event of a crash is acceptable.
Security Testing
No Security testing will occur. There are no security issues.
Stress Testing
Merchandising (General Ledger)
Page 101
The world builder and the engine will be loaded with abnormally high sprite counts (with
attributes and sounds) to determine how much Game Forge can handle.
Performance Testing
The engine will be loaded with an increasing number of sprites while the frame rate is
monitored using the Frame Rate Counter.
2.3 Testing Resources and Staffing
Resources
No special resources are required beyond those already needed for development.
2.4 Test Record Keeping
Test record keeping and Test work Products are described in section 3.4 of Test
Specification Document. For Information these topics, please refer to section 3.4 of the
Test Specification Document.
2.5 Testing Tools and Environment
The proponents are used as testing tools as well as the testing environment. Test data
files will be constructed for unit and integration testing. A Frame Rate Counter is also
used in determining program performance. There are no other special tools or
hardware.
2.6 Test Schedule
3.0 Test Procedure
In this section we will describe the test procedures in detail.
3.1 Software (SCIs) to be tested
For detailed list of the software components items please refer to section 2.1 from the
Test Specification document.
3.2 Testing Procedures
Page 102
In this section we will try to describe over all software specification. We will describe the
methods for all the different tests to perform and will also declare the expected outputs.
3.2.1 Unit Testing
In this method of testing we will test the smallest unit of software called modules. We
will be testing all the important paths to find any errors within the boundary of module.
So here we will apply sort of white box search. We will be testing parts of the software
rather than the entire software. The modules are as follows.
3.2.2 Integration Testing
In this method of testing we will implement the software at the clients location and will
run it. So we will be testing the product on clients network. As art of testing, will be
looking for any signs of the collision between our software components and those of the
clients. We will install the software at the clients site and will run it. We will have several
different other applications open as well. This applications will be the once that have to
interact with our software on normal bases. We will make sure that all the data is saved
correctly and there is no loss of data or database anomalies in the product. We will be
carefully looking for any sort of collision between several different applications.
Page 103
The Data Loader is used to parse information from the datafiles into the Object
Handler.
Expected Results
The system is expected to integrate without major flaws
3.2.3 Validation Testing
Testing Procedure for Validation
The feature and functionality in the final system will be cross-referenced with the
Software Requirements Specification document to verify that the software demonstrates
conformity with the requirements.
Test Cases and their Purpose
Features corresponding to the design requirements will be evaluated.
Expected Results
The software will perform within the specification of the software requirements
document.
3.2.4 High-Order Testing
Recovery Testing
No Recovery testing will occur. While system failures are undesirable, termination of the
program in the event of a crash is acceptable.
Security Testing
Merchandising (General Ledger)
Page 104
Page 105