Procedure for Software Development

8/6/2019 Procedure for Software Development

1/14

ROLTA INDIA LIMITED REV : NEW GSD-307

DOCUMENT NUMBER : GSD - 307

REVISION : NEW

ROLTAMANUAL 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 of14


2/14


REVISION HISTORY

Revision No. Date PageParagraph/

SectionNature of Change

Page 2 of14


3/14


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 of14


4/14


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 & AcronymsISMS 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 of14


5/14


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 aProject. 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 of14


6/14


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

6.1 Planning Stage

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

Page 6 of14

Project

Planning

Requirements

Definition

Design

Development

Integration &

Test

Installation &

Acceptance


7/14


associated with the project, and describe appropriate management and technicalapproaches.

High Level Product requirements are listed out which percolate down to defining allsoftware product requirements. Each requirement is recorded with some minimum

information like title and textual description; although in some instances additionalinformation 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 programmersmay 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 of14


8/14


The development stage takes as its primary input the design elements described in theapproved 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 satisfiesthe requirements and design elements previously documented, and an updated projectplan.

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 of14


9/14


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 ApplicationsAppropriate 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 changes4. 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 of14


10/14


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 trainedadministrators 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 of14


11/14


SVN configuration: Client-Server configuration

An organized, central storage location for the projects software codes

A method for applying meaningful descriptions to every project folder and everysource 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 datastored 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 of14


12/14


Process flow of Change Request

Page 12 of14

Identify change

in Specification

Request Client to

issue an ECR

Receive Client

Approval for the

ECR

A document describing thedetails of additional work along

with the effort estimation is sentto the Client

Identify the need of

any additional

routines / modifyingexisting ones

Modify / Add

routine as

required.

Study relatedprocess/routine for any

changes required.

Data reviewed

by QA / Client

for confirmation

of ECR

implementation

All routines are

maintained on SVN andchanges are tracked.

Close the ECR

Modifications

acceptable?

No

Yes

Update the CR

Database with the

new entry.

Update the CR

Database

accordingly.


13/14


10.0 Software Development Process Flow

Page 13 of14

Receive request for new software/modification of existing software through

the online form

Department Manager evaluates thefeasibility of the software and approves

the implementation

Software Manager estimates the time requirement of developing the softwareand assigns the task to the concerned software developer

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 tothe requestor and changes the status of software

to Closed

The requestor, after checking the softwareagainst his requirements, requests the QA to

certify.

On QA Certification, the software isreleased for final use.

QA tests the software vis--vis requirements.

QA Pass

QA Fail

AA

B

DevelopmentissueRequesting issue

Return toA

Return toB


14/14


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 of14

Documents

Procedure for Software Development