ROLTA INDIA LIMITED REV : NEW GSD-307

DOCUMENT NUMBER : GSD - 307

REVISION : NEW

ROLTA
MANUAL OF INSTRUCTIONS

SUBJECT : Standard Geospatial Services Procedure for Software Development

PURPOSE : To provide details of steps to follow for Software Development

Authorization Name Date

Prepared by: Mahesh Wankhedekar Sept 2009

Reviewed by Deepak Vedak Sept 2009

Approved by (DO) Bob Britton

Page 1 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

REVISION HISTORY

Paragraph/
Revision No. Date Page Nature of Change
Section

Page 2 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

INDEX

S.N. Title Page No

1 Purpose 5
2 Scope 5
3 Definitions & Acronyms 5
4 Responsibilities 6
5 Software Request Origin 6
6 Software Development 8
7 Processing in Applications 11
8 Security of System Files 12
9 Handling Change Request 13
10 Software Development Process Flow 15
11 Software Request Form 16

Page 3 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

Purpose
This procedure defines the implementation of Software Development system in accordance
with the requirements of ISO/IEC 27001:2005 standard. This procedure defines the method
for maintaining the security of application system software and information occurring in
GSD through a formal process. This procedure also ensures that all the software requests
are documented and maintained properly for possible re-use in future.

2.0 Scope
This procedure applies to the control of documents and data pertaining to the projects and
groups of GSD SBG, which are within the scope of implementation of Information Security
Management System.

3.0 Definitions & Acronyms

ISMS Information Security Management System
Author Document Person designated to create or revise a document
Document ISMS procedure, work instruction, manual, or associated form,
which is used to control the processes.
Signature/Sign Handwritten, electronically written, or electronically typed name
of an individual that indicates an act of approval, disapproval,
review, etc.
Procedure A specified way to carry out a process or activity.
Record Document established to provide evidence of conformity to
requirements.
Report Document describing the finding about an activity or incident.
ISM Information Security Manager
SVN SVN
QA Quality Assurance
DDD Design Data Document
CR Change Request
IPR Intellectual Property Rights

Page 4 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

4.0 Responsibilities
The responsibilities for Software request Handling are distributed as follows:

4.1 The Software program Requestor shall:

4.1.1 Identify requirement of new routines or enhancement in the existing routine.

4.1.2 Report the same to the Software Manager through online Software request
form.

4.2 The respective Department Administrators shall:

4.2.1 Review the software request for feasibility and approve its implementation.

4.3. The Software Manager shall:

4.3.1 Act on the Software (Program) Request received.

4.3.2 Estimate time required to complete the software program, assign
development task to software developers.
4.3.3 Undertake regular reviews of the effectiveness of the ISMS taking into
account results of reports, suggestions and feedbacks.

4.4. The software developer shall:

4.4.1 Investigate and determine the details of the software requirement.
4.4.2 Check and confirm, if all parameters required to build the software are
provided by the requestor.

4.5. The Executive Director shall:

4.5.1 Provide appropriate resources to support the ISMS, maintain and continually
improve the ISMS.
4.5.2 Carry out reviews of software request reports and react appropriately to the
results of the reviews.

5.0 Software Requests Origin

5.1 Origination of requisition of software Program

Requests for Software program originate from different sources and at different stages of a
Project. Basically, the needs for software programmes are realized at the time of a) Project
initiation or when the b) Project is already under production.

a) Pilot Projects:
Most of the requests for software program find their origin at the time of
1. Project Kick-off meeting

Page 5 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

2. Finalizing Project specifications

3. Identifying deviation from specifications
4. Project Meeting comprising of Technical Support team, QA team and the
project manager.
b) Projects already under Production:
Most of the software enhancements find their origin at the time when the software is
being used in production. Some new routines also are requested at this stage, but
their numbers are few compared to the initial stages.

Software requests are reported through the online software request form. This form also
helps in the Software review process and serves as a database that helps prevent re-
producing the same software.

6.0 Software Development

Project
Planning

Requirements
Definition

Design

Development

Integration &
Test

Installation &
Acceptance

6.1 Planning Stage

The planning stage establishes an overview of the intended software product, and
uses this to establish the basic project structure, evaluate feasibility and risks

Page 6 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

associated with the project, and describe appropriate management and technical
approaches.

High Level Product requirements are listed out which percolate down to defining all
software product requirements. Each requirement is recorded with some minimum
information like title and textual description; although in some instances additional
information and references to external documents are included.

6.2 Requirement Definition Stage

The requirements gathering process takes as its input, the goals identified in the high-level
requirements section of the project plan.

In this stage, major Function, like input & output data validation, critical processes to be
managed, as well as mission critical inputs, outputs and reports, of the intended application
are defined.

The requirements are fully describe in the Requirements Document. This document contain
complete descriptions of each requirement, including diagrams and references to external
documents as necessary.

The outputs of the requirements definition stage include the requirements document and
an updated project plan.

6.3 Design Stage

The design stage takes as its initial input the requirements identified in the approved
requirements document. For each requirement, a set of one or more design elements may
be produced.

Design elements describes the desired software features in detail, and generally include
functional hierarchy diagrams, screen layout diagrams, tables of business rules, business
process diagrams, pseudo-code, and a complete entity-relationship diagram with a full data
dictionary.

These design elements describe the software in sufficient detail that skilled programmers
may develop the software with minimal additional input.

The outputs of the design stage are the design document and an updated project plan.

6.4 Development Stage

Page 7 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

The development stage takes as its primary input the design elements described in the
approved design document.

For each design element, a set of one or more software artifacts may be produced.

All software codes are maintained on Tortoise SVN (SVN) for ensuring Version
Maintenance, revision history, etc. All codes relating to a project are stored in a folder
created for that particular project. Only software developers and other important team
members assigned for that project have privilege to view the contents of this folder for
security reasons.

The outputs of the development stage include a fully functional set of software that satisfies
the requirements and design elements previously documented, and an updated project
plan.

6.5 Integration & Test Stage

During the integration and test stage, the software artifacts, online help, and test data are
migrated from the development environment to a separate test environment.

The software, in the encrypted format, along with the DDD is provided to the testing team
who perform the entire test using the test cases prepared by them.

All the modules of the software provided to the testing team are in encoded format to
ensure security and prevent leakage of code.

The outputs of the integration and test stage include an integrated set of software, an
acceptance plan, which contains the final suite of test cases, and an updated project plan.

6.6 Installation & Acceptance Stage

During the installation and acceptance stage, the software artifacts and initial production
data are loaded onto the production server. All test cases are run to verify the correctness
and completeness of the software. Successful execution of the test suite is a prerequisite
to acceptance of the software by the customer.

After customer personnel have verified that the initial production data load is correct and
the test suite has been executed with satisfactory results, the customer formally accepts
the delivery of the software.

Page 8 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

The primary outputs of the installation and acceptance stage include a production
application, a completed acceptance test suite, and a memorandum of customer
acceptance of the software.

After receipt of acceptance, the project is locked by Project Manager, by archiving all
software items, the implementation map, the source code, and the documentation for
future reference.

7.0 Processing in Applications

Appropriate controls are designed into applications, including user developed applications
to ensure correct processing. These controls include the validation of input data, internal
processing and output data.

Input Data Validation

Data input to application is validated to ensure that this data is correct and appropriate. The
following check-list is referred to while preparing validation for any application:

1. Limiting fields to specific input data to detect following errors

a. Out-of-range values
b. Invalid characters in data fields
c. Missing or incomplete data
d. Exceeding upper and lower data volume limits
e. Unauthorized or inconsistent control data
2. Periodic review of the content of key fields to confirm their validity and integrity
3. Inspecting hard-copy input documents for any unauthorized changes
4. procedures for responding to validation errors
5. procedures for testing the plausibility of input data

Control of Internal Processing

Validation checks are incorporated into applications to detect any corruption of information
through processing errors or deliberate acts.

The design and implementation of applications ensures that the risks of processing failures
leading to a loss of integrity are minimized.

Some specific areas:

1. The use of add, modify and delete functions to implement changes to data.
a. For any one of these functions, all other are disabled
b. Error handling if any deviation occurs than the intended purpose

Page 9 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

2. A database is maintained for all application running in batch mode; the status of
all processes is maintained in the database and the next process initiates only
after the successful completion of the previous process.
3. Protection against attacks using buffer overruns/overflows.

Output Data Validation

Data output from application is validated to ensure that the processing of stored information
is correct and appropriate to the circumstances.

Output validation includes

1. Plausibility checks to test whether the output data is reasonable.
2. reconciliation control counts to ensure processing of all data
3. providing sufficient information for a reader or subsequent processing system to
determine the accuracy, completeness, precision and classification of the
information

8.0 Security of System Files

Access to system files and program source code is controlled and IT projects and support
activities are conducted in a secure manner. Care is taken to avoid exposure of sensitive
data in test environments. All program source codes are stored and maintained on SVN.

Control of operational software

The updating of operational software applications are only performed by trained

administrators upon appropriate management authorizations.

Applications and operating system software are implemented only after extensive and
successful testing.

The operational software applications are handed over to the IPR department who keeps a
control of all implemented software as well as the system documentation.

Previous versions of application software are retained and are archived together with all
required information and parameters, configuration details and supporting software.

Access control to program source code

Access to program source code and associated items are controlled, in order to prevent
the introduction of unauthorized functionality and to avoid unintentional changes. This is
achieved by central storage of codes in Tortoise SVN.

Page 10 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

SVN configuration: Client-Server configuration

• An organized, central storage location for the project’s software codes

• A method for applying meaningful descriptions to every project folder and every
source code
• Security against multiple writers updating the same code simultaneously
• Added file protection with backup utilities
• Prevents leakage of information since only authorized users can access the data
stored in SVN

9.0 Handling Change Request (CR)

Software development or modifications due to deviations from the DDD, arising from
additional requirements identified by the client or otherwise, should be controlled
systematically.

1. All software codes and DDD are maintained on the Tortoise SVN database,
which automatically maintains version history and assigns version numbers to
the latest modified code or document.
2. For identifying changes in code vis-à-vis changes required by client, all the
software codes carry appropriate comments.
3. The changes in specifications or any additional requirements are received
through a Change request template only which is duly signed or authorized by
the issuing party.
4. Any Change in request is reviewed for any possible changes it may require on
any other procedure.
5. All CR, after implementation, result in updating the DDD and the old version is
identified or disposed accordingly.
6. Every change in software is made only with a proper CR in place.
7. Implementation of CR is ensured and track of all CRs is maintained in a CR
Database.
8. CR requiring change in operating system is reviewed and tested – the process
of incorporating this change follows the normal change request process flow.
(as shown in the following flow chart)

Page 11 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

Process flow of Change Request

Identify change
in Specification

Request Client to A document describing the

issue an ECR details of additional work along
with the effort estimation is sent
to the Client

Receive Client Update the CR

Approval for the Database with the
ECR new entry.

Study related
Identify the need of
process/routine for any
any additional
routines / modifying changes required.
existing ones

All routines are

Modify / Add maintained on SVN and
routine as changes are tracked.
required.

No

Data reviewed
by QA / Client
for confirmation
of ECR
implementation

Modifications
acceptable?
Yes
Update the CR
Database
Close the ECR accordingly.

Page 12 of 14
 ROLTA INDIA LIMITED REV : NEW GSD-307

10.0 Software Development Process Flow

Receive request for new software/
A modification of existing software through
the online form

Department Manager evaluates the

feasibility of the software and approves
the implementation

Software Manager estimates the time requirement of developing the software

and assigns the task to the concerned software developer

B The software developer verifies if all requirements to develop routine are furnished by the
requestor, before starting the development of the routine

The software developer releases the software to

the requestor and changes the status of software
to ‘Closed’

Return to Return to
A B
The requestor, after checking the software
against his requirements, requests the QA to
certify.

Development
Requesting issue
issue

QA Fail QA tests the software vis-à-

vis requirements.

QA Pass

On QA Certification, the software is

released for final use.

Page 13 of 14
ROLTA INDIA LIMITED REV : NEW GSD-307

11.0 Software Request Form

Description of the software requirement can be written in area provided against Routine
Details. Also, provision to attach relevant documents is available.

Page 14 of 14