Vegan ERP Software Audit: BPAS Solutions and SDLC Processes

This document presents an IS audit report on Vegan's ERP software implementation, focusing on business process automation. The audit reviews the Software Development Life Cycle (SDLC) processes, identifies control weaknesses in bid documents, and assesses the alignment of software modules with user requirements. Key findings include inadequate testing, lack of user manuals and training, and deviations from the original bid specifications. The report provides recommendations for improving the SDLC process, enhancing software quality, and ensuring better alignment with Vegan's business needs. The audit also highlights the importance of detailed documentation, user involvement, and adherence to established project management practices. Desklib provides access to a wealth of solved assignments and study resources for students.

Vegan
ERP software to automate business process
Student Name
Institution
Date
1

Vegan
Table of Contents
1.0 Introduction...........................................................................................................................................2
1.1 Background..................................................................................................................................3
2.0 Situation......................................................................................................................................3
2.1 Scope and areas of assignment.........................................................................................................4
3.0 IS Audit Findings and Recommendations of SDLC processes.............................................................4
3.1 General Findings and Recommendations......................................................................................5
3.2 Review of bid documents reveals the following control weaknesses:...........................................7
4.0 Observations on review of BID and acceptance documents..........................................................8
5.0 Information provided to Bidders and selected vendor..........................................................................8
5.1 Observation...........................................................................................................................................9
5.2 Data to be collected during Implementation.........................................................................................9
5.3 Observation...........................................................................................................................................9
6.0 Security..................................................................................................................................................9
6.1 Observation.........................................................................................................................................10
6.2 Deliverables.........................................................................................................................................10
1. Deliverables...................................................................................................................................12
1.0 Introduction
Vegan which is located in the suburbs of Chennai is the brainchild of National Diary
Development Board (NDDB). NDDB was created to promote, finance and support
producer-owned and controlled organizations. NDDB’s programs and activities seek to
2

Vegan
strengthen farmer co-operatives and support national policies that are favorable to
growth of such institutions. Vegan promises to usher in a new chapter to the business of
wholesaling. Vegan has been promoted primarily to promote the interests of farmers by
ensuring that they are able to get best value for their value. It seeks to provide optimal
conditions and new trading opportunities. Vegan acts as an intermediary between the
farmers and buyers. It obtains farmer’s produce through farmer association and makes
it available to buyers through auction. Vegan also provides facilities for farmers for
storage of produce and facilities for banana ripening. Vegan has been designed with
facilities and services that are at par with international standards. Vegan has deployed
state of the art Information technology to meet the current and future needs of their
operations.
1.1 Background
Vegan has contracted with Realtek Software, Pune for developing of business process
application software. Realtek has bid for the project through their consortium of software
development companies. As per the BID, 15 modules and 130 Business processes
were identified for development of software. The management of Vegan has been very
proactive in opting for latest technology, which meets their current and future business
needs. The software was to be developed in JSP with Oracle as the backend and
browser as the client interface. The objective of Vegan was to integrate seamlessly
across the value chain by linking the farmers’ association to Vegan and provide latest
information to buyers using the power of Internet. The Business Process Application
Software solutions were to be deployed within a period of 5 months from the date of
approval. The software was to be developed for 15 departments and 130 business
processes as documented by Realtek as part of their consulting assignment. However,
the software development has been delayed and Vegan has not been able to
computerize its business processes as envisaged. Further, there has been dispute with
the software developer Realtek regarding scope of deliverables and consideration to be
paid for additional requirements.
3

Vegan
2.0 Situation
Vegan has installed the hardware and systems software required for running BPAS
Solution. However, Vegan has found that the software being developed by Realtek is
not meeting the business requirements as identified in documentation whereas Realtek
has been claiming that the software as agreed for all the business processes has been
delivered and it is up to Vegan to deploy the BPAS solutions. Vegan has decided to
have an independent audit of 4 modules of BPAS solutions. The primary objectives of
the assignment are to map whether the software modules of Realtek meet the user
requirements of Vegan as documented and the software has been properly integrated
and has all the features as per the accepted bid documents. The IS Auditors had series
of meetings with Mr. Umesh, Manager, Finance and accounts and Mr. Rahul, IT
manager of Vegan to understand their requirements, Business Process operations of
Vegan and BPAS solution. The IS Audit team also reviewed the documentation and had
a preliminary walk-through of two modules of BPAS to understand the features and
functionality of the modules as available with Vegan. The broad scope of the
assignment was agreed to in a final meeting with CEO where it was decided to audit 4
modules of BPAS and also review the SDLC process adapted by Vegan.
2.1 Scope and areas of assignment
The primary objective of the assignment is to conduct Information Systems Audit of 4
modules of the BPAS solutions being developed by Realtek for Vegan. The IS audit of 4
modules of BPAS would be with the objective of mapping the functionality and features
as available in the software with the agreed documented processes and deliverables.
The integration and security including validations built-in the software would be
reviewed to confirm whether the modules meets identified documented requirements of
Vegan. The scope of this project is to review the observations of the SDLC process
review and provide recommendations for improvement.
3.0 IS Audit Findings and Recommendations of SDLC processes
Extracts from the IS Audit report relating to review of SDLC processes are given below:
4

Vegan
3.1 General Findings and Recommendations
i. Based on review of correspondence, documents and software, it is apparent that
that BPAS has not been tested fully as per requirements of the bid documents
before being demonstrated to Vegan on the Vegan servers. It is noticed that
Realtek has been writing letters to Vegan stating that implementation was under
progress and has been completed. However, the bid documents require the
software to be fully tested by Realtek at their site and should match identified
user requirements as outlined in the processes and activities in bid documents
and control manual. Further, Realtek is expected to meet SDLC standards, which
require a structured methodology of software development including testing, user
acceptance and training. It is apparent that appropriate SDLC standards and
procedures have not been followed in development of software.
ii. The bid document specifies that user manual is provided with the software. We
are informed that no user manual has been provided.
iii. Online help is expected in any software. There is no online help in any of the
modules or menus
iv. The documentation available does not link the manuals and the menus available
in the software. This makes the software extremely difficult for testing and
maintenance
v. We have noticed that User training has not been provided as per the bid
documents.
vi. Software has not been designed in a modular fashion making it difficult to
maintain.
vii. Vegan Marked accepted the bid document on 15th Apr. 2013 and agreement was
executed on 22nd Apr. 2013. The project was to be completed with complete
installation and user training within 5 months from date of acceptance. The
agreed project scope included automation of all 15 departments with 130
business processes of Business Process Automation. BPAS was to be delivered
and implemented by 22nd Sep 2013. However, based on our review, we notice
that the software developed by Realtek is not confirming to the requirements
specified in the bid and acceptance documents.
5

Vegan
viii. The Purchase order includes development, testing and on-site implementation of
the required BPAS for Vegan with a warranty period of 3 months and
maintenance for a period of 1 year from date of implementation. The bid
document envisaged liquidated damages for delays. This has not been enforced
by Vegan as of now.
ix. The documented software processes are at macro level and includes processes,
activities, input and output documents in the bid documents and associated
manuals. However, there are no detailed formats of inputs and outputs. There is
no documentation covering the business process logic and validations.
x. It is apparent from review of records that detailed documentation of the business
process at each of the activity level was not performed. Hence the software has
not been implementable.
xi. It is a commonly accepted practice for the software developer to get a
confirmation from the business process owners about acceptance of
understanding of the business processes, validations, logic, flow, input, output
documents, milestones and deliverables. The SRS documents are expected to
contain these details. However, the SRS documents provided contain only table
definitions with only minimum validations.
xii. The software developer seems to have depended heavily on the prototype of
each of the menu screens. However, the limitation of prototype that it covers
only the menus and does not contain the business logic and validations has not
been considered.
xiii. The software has been developed based on the documented study, which is at a
macro level. It was necessary for the developer to do a detailed systems study
and obtain confirmation from user after completing the study. This has resulted in
the software developer not understanding the full scope of the project and
considering any requests from user as additional requirement.
xiv. It is apparent that software has not been tested to confirm whether it maps with
the business processes, as there is no granular documentation mapping the
business processes related documents and menus designed.
6

Vegan
xv. The software developer has not relied fully on the control manuals, which were
the basis for the development of the software. There is no document confirming
that the software developed maps the requirements of the user as outlined in the
manuals.
xvi. There is no menu sequencing and arrangement of menus as per business
process flow and user requirements. Hence, the software is not very user
friendly.
xvii. The payment terms in the original bid documents reflect the standard payment
procedures for software development. However, the amended payment terms
have resulted in the software developer being paid just on delivery of the
software as per grouping of the modules. The modified payment terms have
resulted in there being no responsibility on the software developer to obtain
confirmation from users after implementation. Payment terms have been
modified without providing for specific deliverables and implementation
3.2 Review of bid documents reveals the following control weaknesses:
i. The bid document has been adapted from project management of a physical
works contract and has not been customized for software development.
ii. The bid document does not include for audit of software or software development
methodology at vendor site. This has not been considered in the bid document.
iii. The bid document should have included a process which provides that the user
and implementer agree to acceptance criteria, handling of changes, problems
during development, user roles, facilities, tools, software, standards and
procedures.
iv. The bid document should have set specific milestones with specific deliverables
and timelines and payment should have been linked. Further, project tracking
should have been done to identify and track whether software development is on
track as agreed.
v. The bid document should have stipulated that the software, documentation and
other deliverables are subject to testing and review prior to acceptance. In
addition, it should require that the end products of completed contract
programming services be tested and reviewed according to the related standards
7

Vegan
by the IT function's quality assurance group and other concerned parties (such
as users, project managers, etc.) before payment for the work and approval of
the end product.
vi. The bid document should have outlined the testing would consist of system
testing, integration testing, hardware and component testing, procedure testing,
load and stress testing, tuning and performance testing, regression testing, user
acceptance testing and, finally, pilot testing of the total system to avoid any
unexpected system failure.
4.0 Observations on review of BID and acceptance documents
We have reviewed the bid documents to confirm whether the software and deliverables
meets the requirements. Our observations on significant areas of deviations are outlined
below. This report includes extracts from BID document (Section IIA: Supplementary
General Conditions of Contract of BID document) and related documents.
Our observations for each of the key areas are given below:
4.1 Training: The successful Bidder shall provide certified training for up to 25
employees, from Vegan on how to use this software application.
4.2 Our Observation: Training is provided to users after software has been fully tested
and accepted by the user. It is apparent that no training has been provided as required
for the employees of Vegan, as this stage Realtek does not seem to have been reached
yet on account of software being still under development.
8

Vegan
5.0 Information provided to Bidders and selected vendor
The business process have been defined and documented. Departmental manuals
have been prepared for 15 departments (including farmer associations and collection
centres), which describe the business process of each department and depict these as
process Flow Diagrams. Input and Outputs have been identified and a control manual
also prepared enumerating the checks and controls to be provided. The selected vendor
will be provided with one set of all departmental manuals, the control manual, process
input and output document, and process automation manual containing data flow
diagrams.
5.1 Observation:
These documents clearly outline all the key processes and activities. It is noticed that
there is no mapping of the menus as available in the software with the relevant
documents. This makes it very difficult to test which of the processes and activities are
provided in the software.
5.2 Data to be collected during Implementation
The selected vendor will interact with Vegan staff at various levels to determine the
information to be gathered or displayed for each interface (screen forms and print-outs)
and layouts of each interface. General common specifications for interfaces such as
symbols, colors, designs, fonts, etc. will be developed by vendor and approved by
Vegan.
5.3 Observation
Although the general common specifications for interfaces has been approved by
Vegan, detailed information about each of the input and output formats have not been
obtained.
9

Vegan
6.0 Security
The bidder must ensure complete security at all levels viz. Users, system administrators
and at network level. The security features at application software should be clearly
defined. The bidder must ensure adequacy of security features at each level to
safeguard against any unauthorized transactions. Since the solution is highly technical
and the business information is sensitive, following security mechanism will be
implemented: There will be three level of security.
1. The user will access the application using a browser. For this the user will use
http protocol, which doesn't allow the user to access-unauthorized portion of the
server data.
2. Access Security: Every user will be given username and password to access the
BPAS application. This will restrict unauthorized access to the BPAS.
3. Program Security: At the program level, wherever any decision is made, further
authentication of that user is done. This adds one extra level of security,
6.1 Observation
 The security at the browser level needs strengthening, as the user is able to
navigate through the software by using the forward and back buttons of the
browser. The software does not validate password when these buttons are used.
 The passwords are not encrypted in tables. Hence, users who have access to
the tables can know every user’s password.
 Review of the database design reveals that in most of the fields have no
validations.
 The option for user entry and authorisation is in same screen. Authorisation
should be built in a separate form where the person authorizing should be able to
only view and authorize.
10

Vegan
 Security has to be built for each of the menus so that management can grant
access rights based on job profile.
6.2 Deliverables
Technical documentation: SDLC Standards should be adhered to. These should
comprise of following:
a. System Requirement Specifications: This document will contain the general scope
of each screen. This document will contain a general system requirement study.
Observation: The Systems requirement specifications when completed would have
provided Realtek with comprehensive understanding of the business processes and
detailed activities performed at each level. This would have preceded by systems
analysis, which would have provided Realtek with understanding of the existing
systems, both in details, what is done, and in principle, why. This implies that a detailed
document is prepared recording the information in a way, which the developer and the
users can understand and agree. This is further refined into a logical specification
Schematic representation and tools such as Data Flow Diagrams (DFD) are widely used
in representing the current systems. An initial set of diagrams based on who actually
performs various tasks, is the physical specification. Refining this, adding more detail
and generally moving away from who a task to what is actually done would results in a
logical specification. The model of the existing system that emerges simply shows what
is done not how it is done, how it might be done, or by whom. At the conclusion of
systems analysis phase, the developer would have a logical model of the existing
system, which has been agreed and corrected by the user. Concurrence of the user for
this logical model must be sought. On completion of the new logical model, using
analysis techniques, the DFDs are levelled and a set of miniature specifications to
support the lowest level DFDs are prepared. Entity models are used to describe the
entity relationship. The design activity will need this specification, which will contain
both broad outlines, and the fine details of what the new system is required to do.
11

Vegan
10. Source Code & Licensing: The Consortium, represented by Realtek Software Pvt.
Ltd (Realtek) will grant to Vegan an exclusive license to access, replicate and use that
portion of the Application Software that is created by members of the Consortium as
part of this assignment in other locations of Vegan engaged exclusively in the business
of collection, auctioning & distribution of fruits & vegetables. The additional payment, for
such additional deployment will be agreed and settled between Vegan & Realtek as the
leader and representative of the Consortium.
The source code that the consortium is providing to Vegan is for the exclusive use of
the Vegan. Vegan cannot resell or distribute it to any other organization or individual or
otherwise profit from the software and the code. The Intellectual property for the
software and the code rests with the entity that created it and will be licensed to Vegan
and its legal successors or assigns only. If Vegan provides the source code to any
vendor, contractor or any other party for the purpose of changing it, Vegan must agree
that it would warrant by clauses in the agreement between Vegan and the said party
that the source code in its entirety shall be returned to Vegan at the end of the
assignment and the party will not retain whole or any part of the code in any form
(electronic, photographic, print or magnetic media) whatsoever. Should Vegan be
wound up or otherwise cease operating as a business without a successor or assign
then the source code in it's entirety, as it exists at that time, will be returned to Realtek
for onward transmittal to the entity that created it.
Observation: Vegan’s requirement was to use the software in all their units. However,
there is an additional cost to be paid for any such use other than at Vegan, Chennai.
1. Deliverables
1. Please provide recommendations on what SDLC model would have been
appropriate for Vegan.
2. Please provide standard approach which can be adapted for improving the
control weaknesses in each of the SDLC process.
12

Vegan
3. Please provide specific controls from best practices which could be adapted by
Vegan to ensure that Vegan is able to take forward and complete the project to
meet current and future business requirements.
13