INTEGRATED SOLUTIONS

SOFTWARE OFFSITE STORAGE POLICY

This document is to be regarded as the official systems audit process within integrated solutions. it is to be maintained under change control by the document control coordinator.

TABLE OF CONTENTS 

1.0 INTRODUCTION 4

2.0 STORAGE POLICIES 4

Software OffSite Storage Policy

1.0 INTRODUCTION

This document describes the Integrated Solutions policy for the off site (non contiguous building) storage of software products (in development and released). It is intended to aid the recovery of any software product version(s) that is in development or currently supported in the field and/or in distribution.

2.0 STORAGE POLICIES

2.1 PRODUCT VERSIONS TO STORE (Golden Copy)

Any product version that is currently supported in the field and/or in software distribution must be stored off site for at least one year, or as stated by the server’s administrator after support is discontinued. This includes new feature and maintenance releases. Off site storage of interim, unofficial, patch release source changes and records is optional but is strongly recommended. If these source changes are not stored off site they should be stored in at least two different (contiguous buildings) on site locations. The intent is to allow the full recovery and recreation of any particular official version of the product in the event one on site storage copy becomes damaged or fails.

2.2 PRODUCT COMPONENTS TO STORE

Any component of a product that is required to fully recreate its binary version must be stored off site. This includes, but is not limited to, all source modules, libraries, source code change records, build environments (make files, compilers), and build instructions. The binary product must be reproducible completely from the stored information. The source is required for ongoing field maintenance capabilities. Storage of the binary product alone is not sufficient.

2.3 in development versions to store

If these source changes are not stored off site they should be stored in at least two different on site locations. The intent is to allow the full recovery and recreation of any particular version of the Assets in the event one on site storage copy becomes damaged or fails.

 

2.4 LOCAL STORAGE LOCATIONS

2.4.1 The Lucent Facility Coverage

In order to leverage the Lucent Facility backup process, all software components connected to the WEB or stored on a machine maintained will be automatically backed-up on a regular basis. These components can either be located directly on a Lucent Facility maintained machine, or, periodically backed up from the local source machine to a machine maintained by the Lucent Facility. The directory structure, and the information backed up must allow the for any active official release of the product. At a minimum, these backups by the Lucent Facility should occur at the time any maintenance or new feature release is made to manufacture. It is preferable that these backups occur daily to protect against loss of work during development.

2.4.2 Non Lucent Facility Coverage

If the Lucent Facility systems are not used, it is up to the team leader to make sure that appropriate backup and off site storage arrangements are made.

2.5 STORAGE RECORDS AND RESPONSIBILITIES

Records of off site storage must be kept on location and offsite. The storage records will indicate the file name, directory information, and date backed up. The development team is responsible for recording the details of which machine is the backup and the directory structure used. These records are to be kept by the team leader. The records must be complete enough for the Development Team Leader to be able to inform the Lucent Facility group of what to retrieve (machine/directories) such that the development team can reproduce the required binary product and version.

If the Lucent Facility services are not used, the team leader is responsible for maintaining records for off site storage similar to what the Lucent Facility uses.